Disclaimer: This mostly relates to React and Redux
As Brandon said the two aren't mutually exclusive, and in fact they aren't really comparable directly. MV* describes an entire application, from the data to the presentation and business logic. Components simply describe a methodology for organizing your view layer, and doesn't necessarily address the state and logic of your application. You could do the other two aspects within your components, as they do in the React documentation, but I wouldn't advise mixing concerns this way.
If you're using a component based architecture for your view layer, you could conceivably use a straightforward MVC implementation using Backbone or something replacing the Backbone views with a React component tree. It's my opinion though that the traditional model pattern doesn't lend itself well to a component system with virtual dom rendering. Models are designed to contain and observe specific aspects of state, where as with a component system (with a virtual dom), you're not focused on what specifically changed within the state and only care about what the new state is so you can re-render your components.
With that in mind, managing your data using a Flux implementation is a better fit, because you gain simplicity by using singletons (or a singleton in the case of Redux) to store state, and forget about creating models to compartmentalize specific aspects of state. Then your business logic could go anywhere, but I would recommend using Redux (or my library ReduRx) and encapsulating your business logic in action creator functions. I wrote an article recently that talks about how to view React / Redux applications specifically outside of the traditional MVC pattern, so if you're interested in more of my thoughts check that out.