Is it common for anyone to get 100+ comments in their code reviews on a routine basis? I would say not. Is it common for people whose code quality "leaves a lot to be desired" to get a lot of comments, absolutely.
However, it also depends on the "rules" of the code review process. EVERYBODY has their own ideas on how something should have been done. If your code review process allows comments to be of the form "You should do it this way instead of that way", then you'll likely get LOTS of comments even for adequate code. If your process is intended to find "defects" then the number of comments should be much smaller.
In my experience, reviews that allow "suggestions" for alternative methods are time wasters. Those "suggestions" should be handled one on one outside the review process. Defect reviews are more useful as they get people to focus on bugs instead of "why didn't you do it like I would have done it?". It also is more useful because there's no denying a bug if someone finds one. Thus, there's no hurt feelings but likely gratitude instead.
UPDATE: With all that said, some code is just plain bad, even if defect free. In that case, the review comment should be a single comment that says something like. "This code needs to be cleaned up. Please postpone the review until the code is discussed with [your name here]." In that case, further review of the code should stop until the comment is rectified.
UPDATE2: @User:Do you discuss your code/design with one of them while you are developing it so you can implement what they are looking for before you get to far doing it your way? Are you changing anything about how you are developing code based on their suggestions or keep thinking your way is fine? Are you learning anything from their comments?
When I am the sw lead on a project, it is my job to be responsible for ALL work products. If I approve a work product then I am claiming the product is acceptable. I want to have a reputation for building quality products. Thus, I have expectations and won't accept less than satisfactory. At the same time I try to teach and explain the reasons for my preferences. Those preferences may not always be ideal (particularly in the eyes of others), but most of those preferences have come from experience. Usually a reaction to avoid repeating the bad ones. Thus, there are a few of my personal "sticklers" that are necessary to get my approval, regardless of pushback.
On the other side, you need to learn the expectations that are necessary to get your work products approved. You can disagree, but since you don't appear to have the authority to over-rule then learn what is expected. I doubt that the team is trying to make you fail. As that makes them look bad also. In that regard, just demonstrate that you are eager to learn (even if you aren't), take what they say and do your best to adapt to their preferences and you'll likely see them back off quite a bit. Maybe find the one that you can at least tolerate and see if they'll do a bit of hand-holding to teach you their ways. Who knows, in the process you may learn something that really could take your skills to the next level.