这些概念应该都很熟悉了，只说一下优缺点：

垂直切分的优缺点：

优点：

• 拆分后业务清晰，拆分规则明确；

• 系统之间容易扩展和整合；

• 数据维护简单

缺点：

• 部分业务表无法join，只能通过接口调用，提升了系统的复杂度；

• 跨库事务难以处理；

• 垂直切分后，某些业务数据过于庞大，仍然存在单体性能瓶颈；

水平拆分的优缺点：

优点：

• 解决了单库大数据、高并发的性能瓶颈；

• 拆分规则封装好，对应用端几乎透明，开发人员无需关心拆分细节；

• 提高了系统的稳定性和负载能力；

缺点：

• 拆分规则很难抽象；

• 分片事务一致性难以解决；

• 二次扩展时，数据迁移、维护难度大。比如：开始我们按照用户id对2求模，但是随着业务的增长，2台数据库难以支撑，还是继续拆分成4个数据库，那么这时就需要做数据迁移了。

总结

世界上的万物没有完美的，有利就有弊，就像数据切分一样。无论是垂直切分，还是水平切分，它们解决了海量数据的存储和访问性能问题，但也随之而来的带来了很多新问题，它们的共同缺点有：

• 分布式的事务问题；

• 跨库join问题；

• 多数据源的管理问题

针对多数据源的管理问题，主要有两种思路：

1. 客户端模式，在每个应用模块内，配置自己需要的数据源，直接访问数据库，在各模块内完成数据的整合；

2. 中间代理模式，中间代理统一管理所有的数据源，数据库层对开发人员完全透明，开发人员无需关注拆分的细节。

读写分离的弊端

读写分离给我们带来的好处是很多的，我们对比一下原始的架构和读写分离的架构，从数据流上看，他们的区别是，数据从写入到数据库，到从数据库取出，读写分离的架构多了一个同步的操作。大家想一想，同步操作的时间是多少，延迟如果太大对系统有没有影响，如果同步挂了怎么办？举一个亲身经历的案例，那时老师在做个人中心的订单列表页，这个功能挺简单，只需要把订单数据取出来，在页面上展示就可以了。但是在做的时候，订单以及订单相关的数据都是从读库取出的，其中就包括支付状态，这个用户非常敏感的字段。就在某一天的某一个时段，突然接到了用户大量的投诉，说用户已经付了钱了，但是订单的状态还是未支付。我也觉得很奇怪，马上要了一个订单号，去数据库里查询，发现订单状态就是未支付呀，没有问题，过了一会，为了保险起见，我还是去写库再查一下这个订单吧，发现写库的订单状态确实是已支付，这下完了，写库和读取的数据不一致，我马上通知DBA，让他去查数据库，他的反馈是同步挂掉了。

大家看到了吧，这就是读写分离的弊端，当同步挂掉，或者同步延迟比较大时，写库和读库的数据不一致，这个数据的不一致，用户能不能接受，订单支付状态这个不一致当然是不能接受的了，其他的业务场景能不能接受呢？这个要对不同的业务场景做具体的分析了。

如何正确的使用读写分离

一些对数据实时性要求不高的业务场景，可以考虑使用读写分离。但是对数据实时性要求比较高的场景，比如订单支付状态，还是不建议采用读写分离的，或者你在写程序时，老老实实的从写库去读取数据。我也咨询过专门做数据同步的机构，他们给出的建议是，如果你做数据的同步，你的网络延迟应该在5ms以内，这个对网络环境要求是非常高的，大家可以ping一下你网络中的其他机器，看看能不能达到这个标准。如果你的网络环境很好，达到了要求，那么使用读写分离是没有问题的，数据几乎是实时同步到读库，根本感觉不到延迟。