sujin190

@blessingcr #17 吞吐、延时和一致性，区块链这货一致性完全就是靠牺牲吞吐和延时来得到的，而且并不能达到保持时序的作用，区块链的逻辑完全就是按照收到消息的顺序提交，然后谁得到的确认多谁有限，没说保证消息时序

kafka 分区保证时序是最容易实现的了，性能不够也可以考虑 mq 分队列啊，逻辑虽然都是一个分区或者一个队列只能有一个消费者来保证时序，但是 mq 的队列数量可以多一些

此外也可以加分布式锁，和多线程编程解决时序一致逻辑一样，其性能损失和冲突率有关，看你这描述，saas 系统的动作都是人产生的，冲突概率应该极低才对，加锁的性能损失可以不计了，加锁也可以放在消息队列后面，那消息队列就可以不用考虑使用分区保证顺序了

如果只是服务器回了 syn-ack 之后客户端都没回 ack 就直接 rst 的话，怎么感觉像是 seq 异常了？

@nc2017 #16 并不是，独立服务并没有用到 redis ，虽然本至还是内存存储的原子计数器，区别就是这个服务对每个 key 的加 1 操作都有独立的超时时间，而且是主动精确超时时间，不像 redis 非精确超时时间，超时后自动减 1 ，并且每个 key 可以设置可以加到的最大值，到这个值之后会 wait ，而这个等待时间也是可以设置的，通过这三个参数就可以设计出不同的限流器，TokenBucketFlow 只是某个特定参数组合的客户端封装实现，服务器这个都只有一个操作，因此性能非常可以，内存使用量也不算特别大

同时每个独立的加 1 操作和其包含的过期时间都是独立同步到从节点的，客户端连接从节点命令会自动发送到主节点，所以客户端这边是整个集群的所有节点都是一样的，多核支持性能不够问题可以通过扩容 cpu 核心数和内存就行，不过因为指令简单，支持的 qps 很高，一般应该不需要考虑性能不够问题