那分享下之前做的项目吧： 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 的框架，挂起实现不要太简单

@janus77 #50 而且 avalonia 也完全支持和 wpf 一样的 await 调度逻辑，搞过 wpf 就知道，c#的这个 await 调度逻辑相比安卓 kotlin 什么的好用太多了，不过就是.net 这个 await 底层的线程调度器设计的是有点坑的，也不知道微软是咋想的，顺便说也不知道哪个大聪明设计的这个 kotlin 协程语法，写起来麻烦不说还破坏代码逻辑而且还不能自动处理和 UI 线程的交互

@shunia #55 移动端页面层级简单交互逻辑很浅，xml 确实没啥优势，不过 PC 端层级复杂，交互逻辑更深的情况下，还是 xml 布局更清楚有优势

@janus77 #50 是的，出发点本来就是开源替换 wpf ，wpf toB 用的人还是很多的，qt 虽然出了很多年了，但是说实话如果搞 toB 大型项目真是天坑，这么多年了，虽然搞了 qml 但是还是没办法和 c++代码直接双向绑定，而且国产话龙芯什么的 qt6 问题真不少，electron 之类的我们好像之前搞过，但是 toB 项目操作复杂，处理的数据量非常大，直接卡死，否则就要弄 native 扩展优化性能也是天坑，而且 c#商业项目其实有不少专做商业组件的公司的，也大多都选择了支持 avalonia

手机端的话毕竟用户群和社区还不行，而且现有的大部分 ui 组件都是客户端的，原生 API 的支持估计也不完善，确实有待发展，不过绘图毕竟统一又直接调用 opengl 绘制不适用原生组件，UI 的一致性和性能估计也有保证

avalonia 相比 flutter 还有就是.net 语言更完善了生态更好，非 UI 相关的大量第三方库是可以直接用而且也被验证过了，毕竟大微软搞了这么多年，以后估计也不大可能放弃

@janus77 #38 差别很大，Xamarin 看下底层还是使用各平台的原生组件，这种问题太多了，性能也不行，一致性也很差，ui 原生组件的差异会引入更多问题，开发大型项目就是天坑

avalonia 则是和 flutter 一样的完全是使用 skia 自绘制的，性能更好，问题更少，开发更方便，安卓和 ios 和 flutter 一样同样是单 activity 自绘制，web 则是整个页面一个 canvas 完全自己绘制组件，直接使用 skia 调用 opengl 自绘制所有组件一致性、性能 flutter 大家相比都知道了，avalonia 在这一点上从设计结构、代码质量、性能上来说一点不差

而且受益于.net 的语言支持，数据绑定、样式处理都很方便，而且相比 pdf 说，虽然界面样式仍然追随 wpf 一样使用 axaml 来编写，但是 avalonia 自己编写了编译时插件，完全在编译时把 axaml 中的 xml 编写的界面样式文件编译为了 c#代码最后在编译为了 clr ，运行时性能完全不比 flutter 的代码构建的界面样式差

@twig #14 avalonia PC 端确实完成度很不错，整体设计也很可以，我们项目算是比较大了迁移也还算顺利，性能超出预期，win macos uos kylinos 表现可以说完全一样，现在完成 win11 和 win10 x86 架构，macos arm 架构，uos 龙芯架构，kylinos 海思 x86 架构测试，win7 的话安装了也正常运行了，而且.net8 支持打包 publish 的时候自包含运行时，所以打包发布安装的时候并不要去必需先安装.net 运行时，所以有搞 tob 业务有客户端又有跨平台需求首选 avalonia 肯定可以

顺便没人关注过 avalonia 这货么，最近公司客户端迁移国产化，调研一番用了一个，百万行代码级项目，刚做完，性能还相当不错，win mac uos 麒麟表现都相当一致，刚开始还担心做了一段时间发现这货做的还是相当复杂完成度还不错了，虽然问题也不少，不够基于.net 生态能用的工具也不少，手机和 web 试了下 demo 也很不错

@wangliran1121 清算对账也不一定要一天一次，如果流水足够高，一般是需要多次清账对账流程才能保证安全，进一步配合不同层级的风控甚至可以进一步依据风控输出决定每个商户在第几次清账后可以支出

个人其实不赞同使用 redis 保存余额的方案，从支付交易的角度来看安全无风险、准确性可靠性之后才应该考虑效率和性能，毕竟在较高的流水下，任何可能存在的事故一旦出现就可能致命甚至更糟，一分钱的异常和 100 块也毫无区别，常规业务中或许无需考虑某些可能存在的异常，但只要支付流水足够高还是不应该忽略

再说吧，这都真金白银付钱了，高并发也毕竟天花板就在哪吧，否则都那么高流水了分区后加钱加机器加人都是不值一提的，实在没必要在技术工程上冒这个风险吧，毕竟问问老板他也会说获得久才能赚得多

@qh666 #36 虽然如此，但是有实际工程经验的都知道没有这么算的吧，峰值容量 1000 但是能稳定维持这量级 7 、8 小时都已经牛逼顶天了，实际情况也就 3 、4 小时能有这量级，我们设计不是在这空中阁楼的瞎意淫而是需要充分考虑实际工程情况和使用场景的，不考虑实际工程情况和使用场景的设计必定是不靠谱的，再说按你这每天数百亿上千亿的流水，就在这几句话就讨论出可靠的解决方方案这也不现实啊，楼主估计想问的也不是这使用场景吧

@wxf666 #33 你这个提的就没道理好吧，当天能有 1.66 亿笔流水么！！每天数百亿上千亿的流水？瞎想可不行，真有这么多，清算对账流程还需要比这复杂得多得多，我说的这种能可靠风险低每天处理数百万千万级流水就不错了，想着小学数学解决登月这就不显然扯淡么
每天几万笔可以用余额加减，这种上亿笔的流水就不可能有简单有可靠又风险低的方案，毕竟就算百万级的异常率，每天损失也高达数百万，亿级别的异常率可不是轻易就能做出来的，不要想着有银弹解决所有问题

@wxf666 #25 只能花已经清算的余额 1w ，也就是<=1w 的钱，这个就是账期，1 天其实大多数商户都能接受

如果你做的是收单那风控和清算是必需的，否则你很可能会面临法律风险
如果你只是对接支付宝微信支付，这么大流水清算对账也是应该考虑的，虽然风控的事情支付宝微信帮你干了，但是毕竟我们自己的服务器和微信支付宝并不是在一起的，万一程序有点啥未知 bug ，那就有可能直接要破产倒闭了还可能面临债务
通过清算对账延迟一点对大家都好，商户看到的余额反正是实时的，并不会收这个账期影响，只是并不能立刻支出这部分钱罢了，而且现实中正常交易都是要么小额收入大额支出，要么大额收入小额支出，小额大量收入同时支出的貌似大都不是正常生意哈

6 楼说的对，这种商户收款付款的打开收支，应该流水优先，一般设计中这种场景都是需要有对账清算的流程的，所以为了提高获取余效率，可以把余额分成已清算余额和未清算余额，已清算的余额可以在对账清算时更新，未清算余额也实时通过流水获取，流水都是不可改的

关于余额扣负这个问题，单个账号流水很大的，大多数系统都存在未清算金额不可以支出的限制，这个既是技术处理的困难，同时也是你还要过风控不可以立即支出，否则反洗钱啥的法律问题叔叔分分钟找上你

对账清算可以自动也可以手动，单账户高并发大量流水没有清算对账无论从技术上看还是从法律上看都是不现实的

既然如此为什么不在放 proto 文件的项目直接生成并发布各个语言的 sdk 包呢，私仓加自动发布就好了啊

@David2077 看起来像是响应超时 5s ，读超时应该有另外的吧

能量密度啊，现在都恨不得直接做一起了，要不是阻抗和散热无法解决，而且现在为了散热效率和稳定性，电池间是打胶加强散热和可靠性的，你这样能量密度起码掉一半，还不说机械故障和热管理故障会大幅提高