秒杀活动在我们看来并不陌生，抽取问题就几点：
1.高并发性，客户量或流量非常大，需要通过负载缓解压力
2.业务实时性，需要即时请求响应
3.数据一致性，需要对事务完整做进一步检查
在活动中，一定不可能是单节点服务器进行操作，不说服务器压力，光是上下行流量就能撑爆带宽，所以分布式技术在高并发场景下应运而生，传统的SSM架构无非是通过Dubbo、Spring Cloud这样的分布式服务框架去解决消息的路由传递，辅以业务锁，事务和队列等技术去解决这类型问题。
如果使用Actor模型进行分布式计算，在akka中，可以将库存抽象成Actor集，用户发出的请求抽象为对这些actor集合接收到的消息，也就是一个SKU对应一个actor。这不就是队列吗？因为actor就是使用队列来接收消息的，这跟传统的使用消息队列解决问题很相似，但还是有所区别，传统的队列只用来解决并发问题，因为解决并发的根本问题就是局部串行化，而使用Actor模型除了使用队列串行并发之外，还进行了分布式的业务逻辑运算，分散了计算能力，传统的方案可能就是将用户的请求放入队列中，然后使用多个消费者处理这些请求，很难做到分布式，如果做成了分布式，那就跟akka差不多了。
上边说到将库存抽象为Actor集，意味着商品库存有多少，就有多少个actor。这不会把内存占满吗？这个问题完全不需要担心，首先，抢购的商品库存一般都比较少，第二点，每个actor自身的大小只需要400左右字节，加上商品的属性计4K，1G内存可以拥有25万多个的actor，并且这些actor可以存在于不同的内存中，理论上只要你有足够的内存，就可以有无限的actor去支持你的商品抢购。
比较困难的是消息的路由传递这一点，假设有一个用户A，他发送了一个抢购请求，这个请求对应的是哪一个具体的actor呢？如果随机发送，那么用户A又发送一个抢购请求，不就会抢购到多个商品了吗？传递一个标记信息给商品actor？如果该商品actor被别人抢购了，如何反应呢？提示失败？不行，因为还存在很多其他未被抢购的actor。转发消息给其他actor？这会导致两点问题，一是整个系统会因此增加大量的无效信息进入actor的MailBox中，二是会造成大量actor在处理消息的发送上耗费时间。
上面提到的问题，可以使用一个或一些actor充当分发器进行处理，使用一些算法，如一致性Hash算法，给予商品和用户一个固定的Hash值，总是比较用户ID的Hash和商品的Hash，将用户消息路由给最接近用户Hash的商品Hash的商品actor上就可以了，但是这个Hash算法必须尽可能分散用户和商品，避免出现热点。这里是第二个难点。
还有就是需要将商品的MailBox类型修改为有界队列。从逻辑上来说，每个商品是一个actor，只能接收一个用户的请求消息，另外为了避免消息过多使得内存满载，必须设置为有界队列，当然队列长度是要大于1的。这里还需要一个作为分发请求的relayActor负责处理后边的请求，若抢购时，队列首请求成功抢购，则该actor负责分发后面的消息到其他的商品actor，以保证所有请求都得到处理。超过这个长度的消息怎么处理呢？在商品被成功抢购之前，可以直接丢弃，因为该请求已经是一个无效请求了，但是这里又有一个问题，队列里有请求并不意味着商品的抢购成功，如果逻辑事务触发，或者数据库写入失败，这时候就可以分配给后面的其他客户。
最后需要计算的是当前商品的库存量，这里也需要一个actor，每个商品actor启动时，给stateActor发送一个消息，当商品被成功抢购之后，给state发送一个消息，同时stop自身，这样state就可以通过自身的邮件队列异步获取当前的库存了。
数据库落库的实现是一个抢购活动的真正完成的标志，因为只有在数据库中写入订单才是抢购成功，那么该如何实现呢？首先，N个商品每个都会有抢购请求，那么就会有N个写数据库的操作，如果为每一个商品actor创建一个数据库连接，那就数据库分分钟就炸了。这里有两种解决方案，一是使用商品actor本身的stateAggregation来完成，当actor触发stop之后，进行数据库更新，二是额外使用单独的actor进行处理。我的建议是使用额外的actor进行处理，因为可能会在1秒钟之内有一万个商品actor触发了stop，这时数据库的压力和上边说的就是一样的，使用额外的actor处理就有点像我们传统使用的MQ操作。
当然这里最好还是使用批量写的操作方式，因为抢购是一个瞬时并发性很高的操作，这意味着我们对数据库操作也是在短时间内完成的，我们可以将数据库操作的请求进行累积，设定一个执行间隔，这样就可以有效缓解数据库的压力。
