好玩的网站列表

1. 微信红包业务特点以及技术难点

1.1 业务特点

类似于线上的秒杀，海量的并发请求；更严格的安全级别，因为牵扯到资金交易，所以就不可以有像用秒杀活动当中的那种超卖的方式。

1.2 流程

• proxy

  • 处理请求接入

• server

  • 主要业务逻辑

• DB

  • 数据持久化
  • 事务级别的完成 - 完全执行或者完全不执行
    • 锁库存
      • 为了避免并发请求时出现超卖情况
      • 技术难点，当大量用户同时做秒杀操作的时候，第一个到达DB的请求锁住了这行库存记录。在第一个事务完成提交之前这个锁一直被第一个请求占用。——> 技术难点，并发请求抢锁
    • 插入秒杀记录
    • 更新库存

• Cache

  • 缓存库存数量

2. 微信红包系统的高并发解决方案

2.1 高并发问题常用方案

2.1.1 使用内存操作替代实时的DB事务操作

server 到内存Cache，做扣库存的操作，然后内存Cache异步持久化到数据库。但是如果内存Cache炸了，或者内存Cache更新，但是DDB没有更新，都会很崩。多个服务器之间的同步也会是一个不小的问题。

2.1.2 使用乐观锁 instead of 悲观锁

• 乐观锁
  • 假设多用户并发的事务处理时不会相互影响。在提交数据更新之前，每个事务会检查在该事务读取数据之后，有没有其他事务又修改了数据。如果其他事务用更新的话，正在提交的事务会进行回滚。
• 悲观锁
  • 阻止一个事务以影响其他用户的方式来修改数据

对于微信红包的使用场景，即需要在DB里维护一个版本号，在更新库存的操作进行之前，先去DB获取当前版本号，然后在更新库存的事务提交的时候，检查是否被修改。

这么做的问题在于：

• 乐观锁，多个用户同时抢红包，那势必只有一个成功，另外的都会显示失败 - 报错，这就用户体验很差劲了
• 而且会造成刚开始可能失败，后面因为并发小了，有成功的案例的可能性
• 大量无效请求，回滚，给DB带来很大压力

2.2 微信红包系统的解决方案

• 系统垂直SET化
  • 生成ID作为红包的唯一标识
  • 红包系统根据ID做垂直切分，一个垂直逻辑链条上的Server和DB们叫做一个SET
  • 各个SET相互独立，且解耦，每个红包ID的所有请求都会在同一个SET当中来处理
    • 看起来像是需要主备两台服务器，备用服务器平常没有流量，完全用来在主服务器出问题的时候，直接转备用
• 逻辑Server层将请求排队，解决DB并发问题
  • 将拆红包的事务操作做串行处理，在Server层做FIFO的排队处理
• memcached控制并发
  • 利用CAS原子累增操作，控制同时进入DB拆红包的请求数，超过预定值就直接拒绝服务，通过这种方式来做DB负载过高时的降级体验
• 双维度库存表设计
  • TTL
  • 冷热数据分离

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 stone2paul@gmail.com