akka设计模式系列-akka在秒杀场景的应用
本博客讨论一下akka在秒杀场景下的应用，提出自己的见解，只做抛砖引玉，大神勿喷。秒杀活动涉及到前中后台各个阶段，为了说明问题，我们简化场景，只研究akka在后台如何处理秒杀业务。
秒杀活动
所谓的秒杀活动，简单点来说，就是把某个稀缺商品或促销商品，挂到页面，供大量客户抢购。这里有两个关键点，商品数量不多，客户量非常大或抢购流量非常大。客户量或抢购流量往往意味着并发量非常大，容易给服务器造成很大的瞬时压力。
同样，为了简化问题，我们把秒杀活动中的概念也进行简化，分为库存和抢购请求。库存：待抢购商品的数量。抢购请求：客户为了抢购商品的点击动作，也就是一次请求。抢购请求分为成功和不成功两种，抢购成功会减少库存，否则不会。
其实在活动中经常会有海量的、重复的、分布的抢购请求，因为同一个客户会点击多次或开多个页面进行抢购。如果处理这些请求的服务器只有一台，其他的不说，这个瞬时流量都不一定能够承受，因为宽带搞不定了啊。所以应该是多少个节点来处理。另外抢购请求是海量的、分布的，这就意味着并发量很大，如果处理不当还可能造成超卖的情况。传统技术解决这个问题，无非就是加锁、用事务、用队列。
我们把抢购请求只划分为成功和失败两种，请大家一定要注意，这里其实我们忽略了付款的问题，因为这会增加问题的复杂度，不利于分析问题。其实吧，付款是可以规避掉的，提前让用户付款，然后再抢购不就好了？抢购成功意味着付款成功。
在akka中，重要的是如何通过actor实现我们的业务逻辑。其实细细分析可以发现，库存就是一个Actor集，每一个商品的实例就是一个actor，也就是一个SKU对应一个actor。抢购请求就是actor收到的消息。
了解akka机制的同学，大概已经知道怎么解决秒杀问题了，不就是把每个商品抽象成一个actor，每个请求抽象成这个actor的消息么？这跟队列没啥区别啊，因为actor就是用队列来接收消息的。这跟传统的使用队列解决问题非常类似，但还是有些区别的。传统的队列只是用来解决并发问题的，毕竟解决并发的根本方法就是局部串行化。抽象成actor除了使用队列把并发编程串行之外，还分散了计算能力。传统的方案中，可能就是把请求塞到队列，然后使用多个消费者处理这些请求，很难做到分布式，如果做成了分布式，其实跟akka就差不多了。
那么究竟该如何用akka解决这个问题呢？
首先每个商品（也就是SKU）抽象成一个actor，库存有多少，就有多少个actor。读者可能会问，会不会把内存撑爆，其实不会。抢购的商品，其库存一般都很低，一般都是千级别的，撑死了万级别的。如果你说你的业务场景是十万级别的，甚至百万级别的，那请你麻烦在下面留言讨论。^_^。每个actor自身大概会占用400字节，1G内存大概可以有250万个actor；如果加上你商品的其他属性或其他信息，姑且算每个actor占用4K的空间，那么1G内存可以生成26万的actor。26万件商品对于常规的秒杀活动，应该足够了。
其次抢购请求抽象成actor的一个消息。那是不是就是简单的把消息发送给actor呢？其实消息路由的过程才是难点。比如用户X发送的抢购消息该发送给哪个商品的actor呢？随机发送？用户发送多次请求，不就会抢购到多个商品？用户ID计算hash之后发送给固定的actor？那如果这个商品被其他人抢到了呢？其实我们还需要一个处理抢购消息的分发器。
还需要一个抢购请求的router。当然也可以不需要。在每个抢购消息发送之前都需要经过该actor，由该actor对消息进行分发。该router的作用，就是把同一个客户的抢购请求路由到固定的商品actor。那如何实现呢？其实也很简单，那就是用一致性HASH。每个商品和用户都会有一个HASH值，总是把用户ID的HASH值跟商品HASH进行比较，把抢购消息路由给与用户ID的HASH值最接近的商品actor上就可以了。但这个HASH算法需要做到尽可能的分散用户和商品，避免出现热点。其实这个actor的设计比较关键，也比较难，我这里只是提供了方案，并没有说明具体的实现细节，请大家见谅。
另外商品actor的邮箱类型需要修改成有界队列。因为每个商品就是一个actor，而每个商品只能买个一个客户，所以严格上来说，这个actor只能接收一个抢购请求。所以商品actor的邮箱类型必须是有界队列，避免消息过多撑爆内存，当然这个队列的长度必须是大于1的。超过这个队列长度的消息怎么办呢？在这个商品被抢购成功之前，其实可以直接丢弃，因为已经有其他客户占用这个商品了。当然，占用不意味着一定能够抢成功，也可能失败，比如触发了反薅羊毛策略，或数据库更新失败。因为队列中还有其他的抢购请求，前面的客户抢购失败，还是可以把该商品分配给其他客户的。
最后还需要计算当前商品的库存，这也需要一个actor。每个商品actor启动时，给stateActor发消息；商品被抢购成功后，给stateActor发消息，同时stop掉自身。这样stateActor就可以异步的获取当前的库存了。
当然秒杀活动，还有其他很多的技术细节。比如商品actor如何更新数据库呢？毕竟不能每个actor都分配一个数据库链接，压力太大；还比如某个商品被抢购成功后，后面的抢购请求消息需不需要分发给其他商品呢；再比如，如果同时有多个秒杀活动又该怎么办呢；还比如使用分布式，由此带来的一致性、通信异常问题如何解决呢。当然了，这些都是可以用akka技术非常优美的解决的，我这里就不啰嗦了，欢迎大家留言讨论。
补充。
在上面的介绍中，我们还忽略了一个很重要的操作，那就是更新数据库，毕竟最终还是需要把订单等信息写到数据库的，而最终落库才是真正的抢购成功。那么该如何落库呢？
我们知道每个商品都会处理抢购请求，也就是说，如果有n个商品，那么至少会有n个写数据库的请求，该由谁来完成呢？
其实有两种方案，一是由stateAggregation 来完成，在收到对应商品actor的stop消息后，更新数据库；二是单独再用一个actor来完成该功能。其实两者都差不多，读者可自行决定。不过我更建议单独用一个actor来完成该功能，因为更新数据库的请求相对来说还是很大的。比如有1万个商品，那么同时就可能有1万个写数据库的请求，相对数据库来说，量还是很大的。此时我们可以用多个actor来完成数据库的写入，此时用一个router，分散更新请求。
不过更新数据库也有两种方案，一种是单条写入，一种是批量写入。其实秒杀这个场景，更适合批量写入。因为抢购的行为是短时间内的，也就意味着更新数据库的请求也是短时间内的。此时我们可以每1000条更新一次数据库，而不必过分考虑批量时间间隔的问题。因为我们可以把更新数据库的请求看成，全部商品一次性发送过来 。批量写入可以大大节省写数据库的时间，这样也能尽可能的把插入数据库的结果返回给商品actor。只不过最后不满1000条的请求会慢一点，要等下一个超时时间后，批量写入。不过这个时间可以设置的很短，比如1秒。这也就意味着，所有的入库请求，最慢时间是1秒。
2018年9月20日
其实无论数据库怎么优化，最终都会成为秒杀活动的瓶颈的，因为是海量（对数据库而言）的并发写啊。有时候解决问题的最好方法，就是避免问题的出现。加一层缓存应该可以的喽？
上面是优化后的架构。外网用户抢购的请求通过多台Nginx进行转发，nginx将同一个用户的请求转发给后面的同一个region。region根据用户ID将其请求转发给相同的shard。shard里面有一组商品，shard会将相同用户的请求分配给相同的商品。但这会造成即使有商品，某特用户也抢不到，其实吧，这算是变相的公平，也就是说，商品会被随机的分发给不同的用户。不过shard的分配算法也可以修改，分给该shard的用户共同争抢该组内的商品。
其实商品actor的信息最终是要落库的，考虑到高并发对数据库的压力是不可承受的，在数据库之前需要一层缓冲。可以使用kafka等其他可以迅速将消息落地的技术或框架，缓冲的数据落地到数据库，可以是一个缓慢的过程，因为抢购成功到最终发货还是需要一段时间的。但这里还有一个问题，就是用户去哪里查询自己已经抢到了呢？数据库，还是缓存？其实吧，要我说，只要告诉用户抢购已经结束（库存为0），不一定要立即告诉他有没有抢到。等缓存的消息全都落库，订单最终生成，再告诉他有没有抢到就好了。
2018年9月20日19:39:47
商品actor如何快速的落库就成了我们的“心头大患”，本来我想只是简单的把订单信息写入到kafka，kafka虽然也可以保证一定写成功，但又引入了第三方框架。为了偷懒，又设计了上面的架构，即用CacheActor替换kafka等消息队列。
CacheActor对订单消息的持久化就是关键了，那该怎么做呢？为了偷懒，我选择了内存映射文件，也就是把订单信息写入本地文件。然后等抢购结束后在读取该文件，再进行落库。另外为了减少文件的大小，我准备使用一个位图保存这些信息。即，用户的序号为2345，则在文件的第2345个byte上面写入255，否则就是0。减少文件大小还可以增加写文件的速度，避免错误的发生。
经测试，在1万个商品，10万个用户，每个用户重复点击100次抢购按钮的情况下，抢购完成的时间为1341毫秒。
机器环境如下：
