随着网上购物消费模式热度的不断提高，网上销售平台上各种促销手段也层出不穷，其中“秒购”已经是各种网站普遍流行的促销方式了。“秒购”对数据的实效性和精确性要求非常高，所以通过分布式运算实现高并发数据处理应该是正确的选择。不过，高并发也意味着高频率的数据操作冲突，而高频使用“锁”又会严重影响效率及容易造成不可控异常，所以又被迫选择单线程运行模式。单线程、分布式虽然表面相悖，不过如上篇博文所述：可以利用akka-cluster-sharding分片可指定调用的特性将一种商品的所有操作放到同一个shard上运算（因为shard即是actor，mailbox里的运算指令是按序执行的）可容许在一个分布式环境下有多个分片来同时操作。如此可在获取分布式运算高效率的同时又保证了数据的安全性和完整性。
虽然通过分布式运算可以实现近实时的“秒购”交易，但每个“秒购”请求都直接被发往一个actor信箱里等待执行，如果在一个短时间内出现超大量请求的话就很可能使shard actor mailbox超载，造成系统崩溃，这时需要一种缓冲机制根据具体负载情况来推送任务。当然，这种机制必须具备数据持久化能力，所以kafka是这个缓冲机制的一个最佳选择。
在这篇讨论里我想通过一个“近实时交易平台nrtxn（near realtime transaction）”项目来示范“用kafka实现分布式近实时交易”具体的设计和实现。
nrtxn的应用方案是这样的：提供一个平台及相关api给平台用户。各用户分别将自己的产品推送到平台数据库由平台托管。用户通过平台提供的http api向nrtxn平台提交交易请求（如库存扣减请求），等待或查询平台返回操作状态回应。
nrtxn的系统流程如下：
用户调用http api提交请求 ->
http-server将请求派送给各用户所属的分片workManager ->
workManager将请求写入kafka ->
kafka reader读出请求并按请求中交易项目将请求发送给项目所属的分片txnProcessor->
txnProcessor完成操作后发送回应至workManager ->
workManager在按请求所属的回应地址将最终回应返回给http server -> 用户获取请求回应
值得注意的是交易请求在到达终点actor txnProcessor传递中途经过了kafka，所以在txnProcessor完成数据操作后需要通过一些actor地址管理才能正确地回应到http server上的请求线程。
我们大致可以从请求内容了解平台提供的功能：
class TxnRequest( //唯一键：shopId+seller+itemCode+reqTime
shopId: String = "",
//托售单位（平台用户）
seller: String = "",
//售货组别
buyer: String = "",
//购货单位
respond: Int = 1,
//1=需要返回操作结果，0=不返回response (fire-and-go)
reqTime: String = "",
//请求时间（yyyyMMddHHmmssSSS）
itemCode: String = "",
//交易项目
reqValue: Double = 0.00, //操作价值
remarks: String = "",
//操作备注
submitTm: String = "",
//提交时间 由系统填写（yyyyMMddHHmmssSSS）
//写入kafka之前填写，读出时超出指定时段视为无效请求
)