1。基本概念概念一：单一数据库概念二：分片分片解决的是“数据太多”的问题，也就是通常所说的“水平分片”。一旦引入分片，势必会面临“数据路由”的新问题，数据应该访问哪个库。路由规则通常有三种方法：(1)Range：范围优点：简单，易于扩展。缺点：各库压力不均（新号段更活跃）。(2)哈希：hash优点：简单，数据均衡，负载均匀。缺点：迁移麻烦（2数据库扩容3数据库数据需要迁移）。（3）统一路由服务：router-config-server优点：灵活性强，业务与路由算法解耦。缺点：每次访问数据库前多查询一次。大多数互联网公司采用的第二种方案：哈希路由。概念三：分组分组解决的是“可用性和性能提升”的问题。分组通常是通过主从复制来实现的。互联网公司数据库的实际软件架构是“分片和分组兼顾”：数据库软件架构，设计什么，至少要考虑以下四点：如何保证数据可用性如何提高数据库读取性能（大部分应用读多写少，读首先会成为瓶颈）如何保证一致性，如何提高扩展性二、如何保证数据可用性？解决可用性问题的思路是：冗余。如何保证站点可用性？冗余站点。如何保证服务的可用性？冗余服务。如何保证数据可用性？冗余数据。数据的冗余会带来一个副作用：一致性问题。1、如何保证数据库“读”的高可用？冗余读取数据库。2.多读库有什么副作用？读写有延迟，数据可能不一致。上图是很多互联网公司的mysql架构。写入还是单点，高可用无法保证。3、如何保证数据库“写”的高可用？冗余写入数据库。可以采用双主互备的方式冗余写入数据库。4.冗余写入库有什么副作用？双写是同步的，数据可能会冲突（比如“自增id”同步冲突）。如何解决同步冲突，常见的解决方法有两种：两个写库使用不同的初值和相同的步长增加id：1写库的id为0,2,4,6...；2写库数据的id为1,3,5,7...；不使用数据的id，业务层自己生成一个唯一的id，保证数据不冲突；阿里云的RDS服务号称高可用，是如何实现的？他们使用类似于“双主同步”的方法（没有从库了）。依然是双master，但是只有一个master提供读写服务，另外一个master是“shadow-master”，只是用来保证高可用，平时不提供服务。master在下，shadow-master在上，虚拟IP漂移，对业务层透明，不需要人工干预。这种方式的优点：读写没有延迟，没有一致性问题；读写的高可用性；缺点是：不能通过增加从库来扩展读取性能；资源利用率为50%，冗余master不提供服务；画外音：所以，高可用RDS是相当昂贵的。3、如何扩展读取性能？提高阅读性能的方法大致有以下三种。首先是增加指标。这个方法不展开。应该提到的是，不同的库可以创建不同的索引。如上图：写数据库没有创建索引；为在线阅读数据库建立在线访问索引，如uid；为离线阅读数据库建立离线访问索引，如时间；第二种扩展读取性能的方法是增加从库。这种方式被大家广泛使用，有两个缺点：从库越多，同步越慢；同步越慢，数据不一致窗口越大；第三种提高系统读取性能的方法是增加缓存。常见的缓存架构如下：上游是业务应用；下游是主库、从库（读写分离）、缓存；如果系统架构实现服务：上游是业务应用；中间是服务；下游是主库、从库、缓存；业务层不直接面对db和cache，service层屏蔽了底层db和cache的复杂性。不管是用master-slave的方式来扩展读性能，还是用cache的方式来扩展读性能，数据都要复制多份（master+slave，db+cache），肯定会造成一致性问题问题。4、如何保证一致性？主从数据库的一致性通常有两种解决方案：1.如果中间件对某个key有写操作，中间件也会在不一致的时间窗口内将这个key的读操作路由到主库。2、“双主高可用”架构，强制读主，主从一致性问题可以得到很大缓解。第二种不一致是db和cache的不一致。另外，建议对于所有允许缓存未命中的业务场景，都应该为缓存中的KEY设置一个超时时间，这样即使出现不一致，也有自愈的机会。5、如何保证数据库的可扩展性？二级数据库双扩：《亿级数据DB秒级平滑扩容》如果不是双扩：《100亿数据平滑数据迁移,不影响服务》也是可以的，就是扩域：《1万属性，100亿数据，架构设计?》这些解决方案有相关文章写过，不过本文不再赘述。数据库软件架构，究竟应该设计什么？可用性、读取性能、一致性和可扩展性。希望对大家系统地了解数据库软件架构有所帮助。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
