沈剑58同城数据库架构最佳实践文库

《沈剑58同城数据库架构最佳实践文库》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、数据库的基本概念基本概念这一块”主要是让大家就一些数据库方面的概念达成一致。单库首先是〃单库J最初的时候数据库都是这么玩的z几乎所有的业务都有这样的—个库。(used)((userl(分片接下来是“分片"，数据库的分片是解决数据量大的问题。如果数据量非常大,就要做水平切分,有一些数据库支持autoshardingo之前58同城也用过两年mongoDB,后来发现autosharding功能不太可控，不知道什么时间进行迁移数据,数据迁移过程中会有大粒度的锁，读写被阻塞，业务会有抖动和毛刺,这些是业务不能接受的，因此现在又迁移回了MySQLo—旦进行分片，就会面临"数据路由"的问题：

2、来了一个请求，要将请求路由到对应的数据库分片上。互联网常用的数据路由方法有三种:(1)第一个是按照数据范围路由，比如有两个分片，一个范围是0-1亿，一个范围是1亿・2亿，这样来路由。这个方式的优点是非常的简单,并且扩展性好，假如两个分片不够了，增加一个2亿亿的分片即可。这个方式的缺点是：虽然数据的分布是均衡的，每一个库的数据量差不多，但请求的负载会不均衡。例如有一些业务场景，新注册的用户活跃度更高，大范围的分片请求负载会更高。(2)第二个是按照hash路由，比如有两个分片,数据模2寻库即可。这个方式的优点是路由方式很简单，数据分布也是均衡的，请求负载也是均衡的。这个方式的缺点是

3、如果两个分片数据量过大，要变成三个分片，数据迁移会比较麻烦,即扩展性会受限。(3)第三个是路由服务。前面两个数据路由方法均有一个缺点，业务线需要耦合路由规则，如果路由规则发生变化，业务线是需要配合升级的。路由服务可以实现业务线与路由规则的解耦，业务线每次访问数据库之前先调用路由服务，来知道数据究竟存放在哪个分库上。接下来是"分组"与"复制"，这解决的是扩展读性能，读高可用的问题。根据经验，大部分互联网的业务都是读多写少。淘宝、京东查询商品，搜索商品的请求可能占了99%,只有下单和支付的时候有写请求。58同城搜索帖子,察看列表页,查看详情页都是读请求,发布帖子是写请求,写请求的量

4、也是比较少的。可见，大部分互联网的场景都读多写少，所以读性能会最先成为瓶颈，怎么快速解决这个问题呢？通常来说，会使用读写分离，扩充读库的方式来提升读性能。同时也保证了读可用性,_台读库挂了,另外一台读库可以持续的提供服务。fuser1-s厦制实际应用：分组*分片常见数据库的玩法综合了"分片"和〃分组"，数据量大进行分片，为了提高读性能，保证读的高可用，进行了分组，80%互联网公司数据库都是这种软件架构。可用性架构实践数据库大家都用z平时除了根据业务设计表结构，根据访问来设计索引之外，还应该在设计时考虑数据的可用性，可用性又分为读的高可用与写的高可用。上图是〃读〃高可用的常见玩法

5、。怎么样保证数据库读库的高可用呢？解决高可用这个问题的思路是冗余。解决站点的可用性问题冗余多个站点，解决服务的可用性问题冗余多个服务，解决数据的可用性问题冗余多份数据。如果用一个读库，保证不了读高可用，就复制读库，一个读库挂了另一个仍然可以提供服务,这么用复制的方式来保证读的可用性。数据的冗余会引发一个副作用,就是一致性的问题。如果是单库，读和写都落在同一个库上，每次读到的都是最新的数据库，不存在—致性的问题。但是为了保证可用性将数据复制到多个地方,而这多个地方的数据绝对不是实时同步的，会有同步时延，所以有可能会读到旧的数据。如何解决主从数据库一致性问题后面再来阐述。很多互联网

6、公司的数据库软件架构都是一主两从或者一主三从，不能够保证〃写〃的高可用,因为写其实还是只有一个库，仍是单点,如果这个库挂了的话，写会受影响。那小伙伴们为什么还使用这个架构呢？刚才提到大部分互联网公司99%的业务都是〃读〃业务,写库不是主要矛盾，写库挂了,可能只有1%的用户会受影响。如果要做到〃写"的高可用，对数据库软件架构的冲击比较大,不一定值得，为了解决1%的问题引入了80%的复杂度，所以很多互联网公司都没有解决写数据库的高可用的问题。怎么来解决这个问题呢？思路还是冗余，读的高可用是冗余读库,写的高可用是冗余写库。把一个写变成两个写,做一个双主同步,一个挂了的话,我可以将写的

7、流量自动切到另外一个，写库的高可用性。用双主同步的方式保证写高可用性会存在什么样的问题？上文提到，用冗余的方式解保证可用性会存在一致性问题。因为两个主相互同步,这个同步是有时延的/很多公司用到auto-increment-id这样的一些数据库的特性，如果用双组同步的架构，一个主id由10变成11;在没有同步过去之前,另一个主又来了一个写请求，也由10变成11,双向同步会同步失败，就会有数据丢失。解决这个双主同步id冲突的方案有两种:(1)—个是双主使用不同的初始值，相同的步长来生成id，—个