数据库软件架构设计些什么
缘起：受@萧田国 萧总邀请，上周五晚上在“高效运维1号群”内分享了《58同城数据库软件架构设计与实践》（这个topic今年在数据库大会上分享过），应组织方要求，发出纪要。
mysql
1、基本概念算法
2、数据库架构设计思路sql
（1）可用性数据库
（2）读性能缓存
（3）一致性微信
（4）扩展性架构
1、基本概念运维
概念一“单库”异步
概念二“分片”性能
分片解决的是“数据量太大”的问题，也就是一般说的“水平切分”。
一旦引入分片，势必有“数据路由”的概念，哪一个数据访问哪一个库。
路由规则一般有3种方法：
（1）范围：range
优势：简单，容易扩展
缺点：各库压力不均（新号段更活跃）
（2）哈希：hash
优势：简单，数据均衡，负载均匀
缺点：迁移麻烦（2库扩3库数据要迁移）
（3）路由服务：router-config-server
优势：灵活性强，业务与路由算法解耦
缺点：每次访问数据库前多一次查询
大部分互联网公司采用的方案二：哈希分库，哈希路由
概念三“分组”
分组解决“可用性”问题，分组一般经过主从复制的方式实现。
互联网公司数据库实际软件架构是：又分片，又分组（以下图）
2、数据库架构设计思路
数据库软件架构师平时设计些什么东西呢？至少要考虑如下四点：
（1）如何保证数据可用性
（2）如何提升数据库读性能（大部分应用读多写少，读会先成为瓶颈）
（3）如何保证一致性
（4）如何提升扩展性
2.1如何保证数据的可用性？
解决可用性问题的思路是=>冗余
如何保证站点的可用性？复制站点，冗余站点
如何保证服务的可用性？复制服务，冗余服务
如何保证数据的可用性？复制数据，冗余数据
数据的冗余，会带来一个反作用=>引起一致性问题（先不说一致性问题，先说可用性）
如何保证数据库“读”高可用？
冗余读库
冗余读库带来的反作用？读写有延时，可能不一致
上面这个图是不少互联网公司mysql的架构，写仍然是单点，不能保证写高可用。
如何保证数据库“写”高可用？
冗余写库
采用双主互备的方式，能够冗余写库
带来的反作用？双写同步，数据可能冲突（例如“自增id”同步冲突）,如何解决同步冲突，有两种常看法决方案：
（1）两个写库使用不一样的初始值，相同的步长来增长id：1写库的id为0,2,4,6...；2写库的id为1,3,5,7…
（2）不使用数据的id，业务层本身生成惟一的id，保证数据不冲突
58同城没有使用上述两种架构来作读写的“高可用”，58同城采用的是“双主当主从用”的方式：
还是双主，但只有一个主提供服务（读+写），另外一个主是“shadow-master”，只用来保证高可用，平时不提供服务。
master挂了，shadow-master顶上（vip漂移，对业务层透明，不须要人工介入）
这种方式的好处：
1）读写没有延时
2）读写高可用
不足：
1）不能经过加从库的方式扩展读性能
2）资源利用率为50%，一台冗余主没有提供服务
那如何提升读性能呢？进入第二个话题，如何提供读性能。
2.2如何扩展读性能？
提升读性能的方式大体有三种，第一种是创建索引。这种方式不展开，要提到的一点是，不一样的库能够创建不一样的索引。
写库不创建索引；
线上读库创建线上访问索引，例如uid；
线下读库创建线下访问索引，例如time；
第二种扩充读性能的方式是，增长从库，这种方法你们用的比较多，可是，存在两个缺点：
（1）从库越多，同步越慢
（2）同步越慢，数据不一致窗口越大（不一致后面说，仍是先说读性能的提升）
58同城没有采用这种方法提升数据库读性能（没有从库），采用的是增长缓存。常见的缓存架构以下：
上游是业务应用，下游是主库，从库（读写分离），缓存。
58同城的玩法是：服务+数据库+缓存一套
业务层不直接面向db和cache，服务层屏蔽了底层db、cache的复杂性。为何要引入服务层，今天不展开，58采用了“服务+数据库+缓存一套”的方式提供数据访问，用cache提升读性能。
无论采用主从的方式扩展读性能，仍是缓存的方式扩展读性能，数据都要复制多份（主+从，db+cache），必定会引起一致性问题。
2.3如何保证一致性？
主从数据库的一致性，一般有两种解决方案：
（1）中间件
若是某一个key有写操做，在不一致时间窗口内，中间件会将这个key的读操做也路由到主库上。
这个方案的缺点是，数据库中间件的门槛较高（百度，腾讯，阿里，360等一些公司有，固然58也有）
（2）强制读主
58的“双主当主从用”的架构，不存在主从不一致的问题。
第二类不一致，是db与缓存间的不一致
常见的缓存架构如上，此时写操做的顺序是：
（1）淘汰cache
（2）写数据库
读操做的顺序是：
（1）读cache，若是cache hit则返回
（2）若是cache miss，则读从库
（3）读从库后，将数据放回cache
在一些异常时序状况下，有可能从【从库读到旧数据（同步尚未完成），旧数据入cache后】，数据会长期不一致。
解决办法是“缓存双淘汰”，写操做时序升级为：
（1）淘汰cache
（2）写数据库
（3）在经验“主从同步延时窗口时间”后，再次发起一个异步淘汰cache的请求
这样，即便有脏数据如cache，一个小的时间窗口以后，脏数据仍是会被淘汰。带来的代价是，多引入一次读miss（成本能够忽略）。
除此以外，58同城的最佳实践之一是：建议为全部cache中的item设置一个超时时间。
说完一致性，最后一个话题是扩展性。
2.4如何提升数据库的扩展性？
原来用hash的方式路由，分为2个库，数据量仍是太大，要分为3个库，势必须要进行数据迁移，58同城有一个很帅气的“数据库秒级扩容”方案。
如何秒级扩容？
首先，咱们不作2库变3库的扩容，咱们作2库变4库（库加倍）的扩容（将来4->8->16）
服务+数据库是一套（省去了缓存）
数据库采用“双主”的模式。
扩容步骤：
第一步，将一个主库提高
第二步，修改配置，2库变4库（原来MOD2，如今配置修改后MOD4）
扩容完成
原MOD2为偶的部分，如今会MOD4余0或者2
原MOD2为奇的部分，如今会MOD4余1或者3
数据不须要迁移，同时，双主互相同步，一遍是余0，一边余2，两边数据同步也不会冲突，秒级完成扩容！
最后，要作一些收尾工做：
（1）将旧的双主同步解除
（2）增长新的双主（双主是保证可用性的，shadow-master平时不提供服务）
（3）删除多余的数据（余0的主，能够将余2的数据删除掉）
这样，秒级别内，咱们就完成了2库变4库的扩展。
OK，今天主要分享了58同城，数据库软件架构上：
（1）如何保证数据可用性
（2）如何提升数据库读性能
（3）如何保证数据一致性
（4）如何进行秒级扩容
但愿你们有收获，谢谢你们！
===【完】===
实时好文，欢迎长按关注“架构师之路”
==好文推荐==
回【join】秒懂SQL中各类join
回【负载】一幅图秒懂LoadAverage
回【秒杀】秒杀系统架构优化思路（火）
回【招聘】入职58到家
回【微信】微信为什么这么省流量（火）
==小游戏==
回大于10的整数，返回随机好文（猜猜怎么实现的）
码字不易，求帮转哈