微信红包架构

包发抢拆

二倍均值法拆包

抢红包——拆包算法——要解决并发问题

加锁能解决问题，但肯定影响性能。

那怎么做呢？——预分配红包

支付完成后，在后台算好，暂存起来，有人抢的时候，直接拿就好了。

预分配怎么实现呢？

发红包的时候，把金额算好，把金额存进redis的list链表中，每次抢的时候，从list中拿，同时用hash结构来存一下谁抢了多少钱，就可以查询红包领取列表了。
但是，这样的方案支撑不了日均百亿级

redis集群解决日均百亿级

一个redis也就最多几万级并发。同时集群的运维也是问题（比如，某一个节点挂了怎么办？）

但微信没有用预分配方案哦——内存消耗过大——cas

redis用的是内存呀，对于微信来说，存储的东西太多了。
微信用的实时拆包——那怎么解决并发问题呢？
cas

第一次发红包的时候记录版本号，
CAS容易失败，会不会把cpu干烧？——我们可以在cas失败的时候休眠一下。
cas是在内存计算的，效率很高。
但redis不能原生支持cas操作，微信自研了ckV缓存框架,可以大致理解为支持cas的redis，不开源。

我们要实现的尽量要无锁、原子化，实时拆包。
我们可以采用类似的做法——lua脚本实现cas

Java脚本会有并发问题，改为lua脚本就没有并发问题了。
因为lua脚本执行的时候具有原子性，假如多个线程执行这段lua脚本，没关系，这三段lua脚本在redis中是单线程执行的。（redis直接在服务端执行，只需要一次IO，效率就高了）。

查询红包领取记录会很频繁的查询，从redis中查询hash，这个操作会导致redis压力增大——多级缓存

那么对于我们的集群架构，在多态web应用的机器上，更新某一台机器的数据，其他进程的数据就是老数据了，我们的hash数据可能不一致。
我们要同步数据，从产品角度来说，没有必要实时让客户看到最精准的红包领取列表，一直不更新也不行，那怎么做呢？——给ehcache设置一个较短的过期时间，过期了从redis中拿最新的。

异地多活架构

多机房异地部署肯定可以解决高可用问题，那公平性问题怎么解决？
（在深圳发，肯定深圳抢红包最快），怎么解决呢？
上海抢红包的时候，在上海的接入层，通过专线直接路由到深圳的红包系统，已经在极大的保障公平了，世界上没有绝对公平的事情。

柔性降级方案

我们最终可以使用mq将数据异步到db中去，那redis出问题了怎么办？这就涉及到柔性降级方案。

海量数据存储架构

redis的数据只放一天，最终的数据肯定还是要存到DB中去，那就又有问题了，一天几百亿的红包，mysql单表几千万就有性能问题了，那怎么设置存储的架构呢？落地到DB的存储怎么做，以及后面的查询怎么查询？

后面的这些都是广告了没什么硬东西