System.ReactiveX rxjs rxjava

支持楼主。

借楼贴一下自己的伪造跑步数据的项目，给有需求的人。https://github.com/crclz/ExtremeRunning

加油

不要急功近利啊，要厚积薄发。
有的人有 100 颗 star 的实力，却期望着自己的项目拥有 1000 颗 star 。
有的人的项目拥有 1000 个 star，殊不知别人的实力是 10000 颗 star

node 写后端不是折磨？有好的东西不用

如果你真正理解了 CAP，就不会认为 CAP 是一道三选二的选择题了

说实话如果你对 asp.netcore 稍微有一点深入的实践，就可以很轻松的理解 springboot 的各式各样的概念

先学会 C#/java 怎么 DDD，你就知道 go 怎么 DDD 了 https://github.com/dotnet-architecture/eShopOnContainers

看看那条查询的性能分析

安全问题已经解决了，微软的 blazor，小程序的云函数。但是本质上只是前后端耦合加强，并且前后端放在同一个项目里面罢了。该懂的东西还是要懂。

你是 skateholder 吗

其实框架这些东西只占很小的一部分，并且很多东西都是互通的。后端学了 asp.netcore 后，spring 无师自通，只需要查查搜索引擎即可。前端学了 angular 之后，感觉 vue 和 react 都是小菜一碟。

> 问题 1 、虽然 log 表确实必须得有，但是订单的统计为什么不能直接在订单操作的过程中直接把相关的数据写入统计表，而是要异步的定时任务去做？

因为统计数据的更新是订单操作事件的**副作用**。

副作用是一定会成功的，因为并没有事务关系（如果你下单成功了，那么统计数据中的订单数量一定能够加 1，没有业务规则能够阻碍统计数据的改变）。

如果你把订单操作和副作用放在同一个事务里面，那么就会降低响应时间和吞吐量。


> 2 、这样的设计有什么好处吗？

第一，解耦。订单处理只需要考虑怎么处理订单，以及订单的操作应当写哪些日志。至于日志怎么做统计信息，订单处理的程序不需要考虑。

第二，batching 。如果日志处理和修改某些统计信息可以是批量的，那么这种 batching 可以提升速度（ 10 次订单数量+1 操作，vs 1 次订单数量+10 操作）

> 3 、更合适的方案是怎样的？

首先，如果想要做到实时，可以考虑“推”方式的消息队列。

其次，如果系统本身并发要求不高，那么应当采取把订单操作和副作用放在同一个事务里面进行提交，这可以**简化编程**。

原来的方案虽然性能较好，但是把副作用从事务里拆出，需要保证两点：1. log 是 1 次或多次送达的。2. log 可以被重复消费。

第一点可以使用 outbox pattern + ack 来保证；第二点可以让消费者建立去重表。 我所说的这两点是标准的解决方案。

可以看出提升性能的代价就是开发复杂度的增加。

卖企业级崴孩嘞

企业级铁观音

{ {图片名 = "开始_结束比赛.bmp",点击 = {x=1147,y=547}}; {图片名 = "开始_结束比赛_是否退出.bmp",点击 = {x=384,y=375}}; }

你提到的这种方案其实已经是很简洁的了。如果要更简洁，可以用人类友好的配置语言，例如 yaml：

对于图片判断比较耗时的结果（游戏出现 1 个画面，但是要比较 n 次，如果我没理解错的话），你可以采用：
1. 神经网络。用训练好的模型的末尾某一层作为 embedding （例如，可以理解为一个 256 维的向量），预先计算保存数据库中所有图片的 embedding 。当遇到游戏画面的时候，计算一次 embedding （记为 A ），然后把 A 和数据库中的 embedding 做夹角余弦，找出最大的值。（非常快）
2. 手动设计一种图片的相似哈希，例如平均的 RGB，或者分块的平均 RGB 。
3. 进入游戏的虚拟内存空间去做事情（你懂的）

哈哈，这就是 go，你想做 java 的事情，走一步掉一步坑。
可以考虑代码生成