江苏龙网

  1. 主页 > 生活百科 > >

秒杀系统架构分析与实战( 四 )

秒杀系统架构


文章插图
###4.4.2 设计思路### 数据库软件架构师平时设计些什么东西呢？至少要考虑以下四点：

  1. 如何保证数据可用性；
  2. 如何提高数据库读性能（大部分应用读多写少，读会先成为瓶颈）；
  3. 如何保证一致性；
  4. 如何提高扩展性；
  • 1. 如何保证数据的可用性？
解决可用性问题的思路是=>冗余
如何保证站点的可用性？复制站点，冗余站点
如何保证服务的可用性？复制服务，冗余服务
如何保证数据的可用性？复制数据，冗余数据
数据的冗余，会带来一个副作用=>引发一致性问题（先不说一致性问题，先说可用性） 。
  • 2. 如何保证数据库“读”高可用？
冗余读库
秒杀系统架构分析与实战

文章插图
冗余读库带来的副作用？读写有延时，可能不一致
上面这个图是很多互联网公司MySQL的架构，写仍然是单点，不能保证写高可用 。
  • 3. 如何保证数据库“写”高可用？
冗余写库
秒杀系统架构分析与实战

文章插图
采用双主互备的方式，可以冗余写库带来的副作用？双写同步，数据可能冲突（例如“自增id”同步冲突）,如何解决同步冲突，有两种常见解决方案：
  1. 两个写库使用不同的初始值，相同的步长来增加id：1写库的id为0,2,4,6...；2写库的id为1,3,5,7...；
  2. 不使用数据的id，业务层自己生成唯一的id，保证数据不冲突；
实际中没有使用上述两种架构来做读写的“高可用”，采用的是“双主当主从用”的方式：
秒杀系统架构分析与实战

文章插图
仍是双主，但只有一个主提供服务（读+写），另一个主是“shadow-master”，只用来保证高可用，平时不提供服务 。master挂了，shadow-master顶上（vip漂移，对业务层透明，不需要人工介入） 。这种方式的好处：
  1. 读写没有延时；
  2. 读写高可用；
不足：
  1. 不能通过加从库的方式扩展读性能；
  2. 资源利用率为50%，一台冗余主没有提供服务；
那如何提高读性能呢？进入第二个话题，如何提供读性能 。
  • 4. 如何扩展读性能
提高读性能的方式大致有三种，第一种是建立索引 。这种方式不展开，要提到的一点是，不同的库可以建立不同的索引 。
秒杀系统架构分析与实战

文章插图
写库不建立索引；
线上读库建立线上访问索引，例如uid；
线下读库建立线下访问索引，例如time；
第二种扩充读性能的方式是，增加从库，这种方法大家用的比较多，但是，存在两个缺点：
  1. 从库越多，同步越慢；
  2. 同步越慢，数据不一致窗口越大（不一致后面说，还是先说读性能的提高）；
实际中没有采用这种方法提高数据库读性能（没有从库），采用的是增加缓存 。常见的缓存架构如下：
秒杀系统架构分析与实战

文章插图
上游是业务应用，下游是主库，从库（读写分离），缓存 。
实际的玩法：服务+数据库+缓存一套
秒杀系统架构分析与实战

文章插图
业务层不直接面向db和cache，服务层屏蔽了底层db、cache的复杂性 。为什么要引入服务层，今天不展开，采用了“服务+数据库+缓存一套”的方式提供数据访问，用cache提高读性能 。
不管采用主从的方式扩展读性能，还是缓存的方式扩展读性能，数据都要复制多份（主+从，db+cache），一定会引发一致性问题 。
  • 5. 如何保证一致性？
主从数据库的一致性，通常有两种解决方案：
1. 中间件
秒杀系统架构分析与实战

文章插图
如果某一个key有写操作，在不一致时间窗口内，中间件会将这个key的读操作也路由到主库上 。这个方案的缺点是，数据库中间件的门槛较高（百度，腾讯，阿里，360等一些公司有） 。
2. 强制读主
秒杀系统架构分析与实战

文章插图
上面实际用的“双主当主从用”的架构，不存在主从不一致的问题 。
第二类不一致，是db与缓存间的不一致：
秒杀系统架构分析与实战


推荐阅读


上一篇：别人给你倒茶时 为何定要敲三下桌面

下一篇：日常饮茶 怎么做个有礼貌的饮茶人