沈剑：58同城数据库架构最佳实践.docVIP

数据库的基本概念 基本概念这一块，主要是让大家就一些数据库方面的概念达成一致。 首先是“单库”，最初的时候数据库都是这么玩的，几乎所有的业务都有这样的一个库。 接下来是“分片”，数据库的分片是解决数据量大的问题。如果数据量非常大，就要做水平切分，有一些数据库支持auto sharding。之前58同城也用过两年mongoDB，后来发现auto sharding功能不太可控，不知道什么时间进行迁移数据，数据迁移过程中会有大粒度的锁，读写被阻塞，业务会有抖动和毛刺，这些是业务不能接受的，因此现在又迁移回了MySQL。 一旦进行分片，就会面临“数据路由”的问题：来了一个请求，要将请求路由到对应的数据库分片上。互联网常用的数据路由方法有三种： （1）第一个是按照数据范围路由，比如有两个分片，一个范围是0-1亿，一个范围是1亿-2亿，这样来路由。?这个方式的优点是非常的简单，并且扩展性好，假如两个分片不够了，增加一个2亿-3亿的分片即可。?这个方式的缺点是：虽然数据的分布是均衡的，每一个库的数据量差不多，但请求的负载会不均衡。例如有一些业务场景，新注册的用户活跃度更高，大范围的分片请求负载会更高。 （2）第二个是按照hash路由，比如有两个分片，数据模2寻库即可。?这个方式的优点是路由方式很简单，数据分布也是均衡的，请求负载也是均衡的。?这个方式的缺点是如果两个分片数据量过大，要变成三个分片，数据迁移会比较麻烦，即扩展性会受限。 （3）第三个是路由服务。前面两个数据路由方法均有一个缺点，业务线需要耦合路由规则，如果路由规则发生变化，业务线是需要配合升级的。路由服务可以实现业务线与路由规则的解耦，业务线每次访问数据库之前先调用路由服务，来知道数据究竟存放在哪个分库上。 接下来是“分组”与“复制”，这解决的是扩展读性能，读高可用的问题。 根据经验，大部分互联网的业务都是读多写少。淘宝、京东查询商品，有哪些信誉好的足球投注网站商品的请求可能占了99%，只有下单和支付的时候有写请求。 58同城有哪些信誉好的足球投注网站帖子，察看列表页，查看详情页都是读请求，发布帖子是写请求，写请求的量也是比较少的。 可见，大部分互联网的场景都读多写少，所以读性能会最先成为瓶颈，怎么快速解决这个问题呢？ 通常来说，会使用读写分离，扩充读库的方式来提升读性能。同时也保证了读可用性，一台读库挂了，另外一台读库可以持续的提供服务。 常见数据库的玩法综合了“分片”和“分组”，数据量大进行分片，为了提高读性能，保证读的高可用，进行了分组，80%互联网公司数据库都是这种软件架构。 可用性架构实践 数据库大家都用，平时除了根据业务设计表结构，根据访问来设计索引之外，还应该在设计时考虑数据的可用性，可用性又分为读的高可用与写的高可用。 上图是“读”高可用的常见玩法。怎么样保证数据库读库的高可用呢？解决高可用这个问题的思路是冗余。 解决站点的可用性问题冗余多个站点，解决服务的可用性问题冗余多个服务，解决数据的可用性问题冗余多份数据。 如果用一个读库，保证不了读高可用，就复制读库，一个读库挂了另一个仍然可以提供服务，这么用复制的方式来保证读的可用性。 数据的冗余会引发一个副作用，就是一致性的问题。 如果是单库，读和写都落在同一个库上，每次读到的都是必威体育精装版的数据库，不存在一致性的问题。 但是为了保证可用性将数据复制到多个地方，而这多个地方的数据绝对不是实时同步的，会有同步时延，所以有可能会读到旧的数据。如何解决主从数据库一致性问题后面再来阐述。 很多互联网公司的数据库软件架构都是一主两从或者一主三从，不能够保证“写”的高可用，因为写其实还是只有一个库，仍是单点，如果这个库挂了的话，写会受影响。那小伙伴们为什么还使用这个架构呢？ 刚才提到大部分互联网公司99%的业务都是“读”业务，写库不是主要矛盾，写库挂了，可能只有1%的用户会受影响。 如果要做到“写”的高可用，对数据库软件架构的冲击比较大，不一定值得，为了解决1%的问题引入了80%的复杂度，所以很多互联网公司都没有解决写数据库的高可用的问题。 怎么来解决这个问题呢？思路还是冗余，读的高可用是冗余读库，写的高可用是冗余写库。把一个写变成两个写，做一个双主同步，一个挂了的话，我可以将写的流量自动切到另外一个，写库的高可用性。 用双主同步的方式保证写高可用性会存在什么样的问题？ 上文提到，用冗余的方式解保证可用性会存在一致性问题。因为两个主相互同步，这个同步是有时延的，很多公司用到auto-increment-id这样的一些数据库的特性，如果用双组同步的架构，一个主id由10变成11，在没有同步过去之前，另一个主又来了一个写请求，也由10变成11，双向同步会同步失败，就会有数据丢失。 解决这个双主同步id冲突的方案有两种： （1）一个是双主使用不同的初始值，相同的步长来生成i