共计 640 个字符，预计需要花费 2 分钟才能阅读完成。
- 背景
- 挑战
- 指标
背景
面对日益减少的零碎访问量，数据库的吞吐量面临着微小瓶颈。对于同一时刻有大量并发读操作和较少写操作类型的利用零碎来说，将数据库拆分为主库和从库，主库负责解决事务性的增删改操作，从库负责解决查问操作，可能无效的防止由数据更新导致的行锁，使得整个零碎的查问性能失去极大的改善。
通过一主多从的配置形式，能够将查问申请平均的扩散到多个数据正本，可能进一步的晋升零碎的解决能力。应用多主多从的形式，岂但可能晋升零碎的吞吐量，还可能晋升零碎的可用性，能够达到在任何一个数据库宕机，甚至磁盘物理损坏的状况下依然不影响零碎的失常运行。
与将数据依据分片键打散至各个数据节点的程度分片不同，读写拆散则是依据 SQL 语义的剖析，将读操作和写操作别离路由至主库与从库。
读写拆散的数据节点中的数据内容是统一的，而程度分片的每个数据节点的数据内容却并不相同。将程度分片和读写拆散联结应用，可能更加无效的晋升零碎性能。
挑战
读写拆散尽管能够晋升零碎的吞吐量和可用性，但同时也带来了数据不统一的问题。这包含多个主库之间的数据一致性，以及主库与从库之间的数据一致性的问题。并且，读写拆散也带来了与数据分片同样的问题，它同样会使得利用开发和运维人员对数据库的操作和运维变得更加简单。下图展示了将分库分表与读写拆散一起应用时，应用程序与数据库集群之间的简单拓扑关系。
指标
透明化读写拆散所带来的影响，让应用方尽量像应用一个数据库一样应用主从数据库集群，是 ShardingSphere 读写拆散模块的次要设计指标。