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

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

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

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

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

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

@zhouhuab MTM2OTAzOTcyMA== 可以加 q

@zhouhuab 那就更不要 7 层代理了，按理说心跳至少可以到 2 分钟，微信之前还发过文研究过 4 到 5 分钟也撑得住，估计给个 3 分钟估计可以，ws 的心跳包好像只有 3 字节吧，算上 ip tcp 头，100 万设备全天在线一个月估计也就 1T 多流量，你这咋高这么多。。

@zhouhuab 都这设备数量级了，还用啥 7 层代理吧，4 层都用不起，直接 dns 均衡足够了，否则太浪费资源了，且不说内存使用量大增加了不少，光是心跳就要增加不小的 cpu 使用率了，而且还要考虑重启更新或者网络中断啥的集中重连需要预留资源的消耗也更多，也就是如果你平时就内存 cpu 带宽全满那重启就有可能没有足够资源起得来了

@HaroldFinchNYC 都运行良好，性能很不错，而且一致性非常好，可以说完全一致，我们完成了 macos 的 arm64 ，uos 的龙芯芯片，银河麒麟的海思 x86 芯片的测试，完全不比 win 差，并且.net8 现在打包时可以选择报告运行时，所以安装完直接可以用，并不需要先安装.net 运行时

@profchaos 确实界面 xml 的热重载几个 ide 支持都有问题，不过.net 的热重载倒是微软搞的，不过 xaml 文件 avalonia 中还是被编译为 c#代码了不是运行时加载的，不知道微软 c#的热重载咋搞的，否则还真不好弄

@RichardPlus 公司的商业项目用 Avalonia 重做完了，性能和兼容性都还可以。win7 上也能正常运行，挺好的

那分享下之前做的项目吧： https://github.com/snower/jaslock-spring
有令牌限流 TokenBucketFlow 实现，性能肯定够用，我们自己项目也再用

非 spring 的原始 java driver: https://github.com/snower/jaslock

需要用服务端： https://github.com/snower/slock 也支持高可用部署，支持多核，性能不够加内存加机器 cpu 核心就好了

@SeaTac #47 时间直接就变了啊？！！我还以为只是修改作息，时间不变，比如夏令时 9 点上班，冬令时 10 点上班，直接调时间感觉好坑好难受

互联网公司用的很少，ToB 商业项目还是有不少人用的，总的开发者和企业用户群都小很多，而且很多客户端需求也可以用网页平替，撑个 15 年肯定没问题，ToB 业务不是那么容易消亡的

其实这种还是使用 long polling 轮询实现更简单快捷，搞个异步 IO 的框架，挂起实现不要太简单