@
b00tyhunt3r 我想说的就是类似这样的问题，很多游戏服务端看起来好像解决了这个问题，实际上连最终一致性都没法保证
就以这个例子：玩家背包物品至场景地图再至另外玩家背包，大部分游戏实现是玩家背包物品在玩家 Actor 中（为了方便大量的养成玩法直接改变消耗背包物品），场景地图中的这块区域又是一个单独的 Actor 。Actor 与 Actor 的某一次通信，没有保证（也很难保证）绝对送达且只送达一次。
就我看过的所有实现都是，actor 发送个消息，改变自己的数据，做的更进一步的是会等待一个回复。整个过程实际上是一个事务过程，游戏服务端一般数据都是存储在内存中直接操作，绝大部分实现没有保证布操作是事务的。这个实现过程几乎就是一个不出问题就不出问题的实现。打架默认都是走事后补偿路线。
我在游戏行业十多年了，客户端服务端都写过不少垃圾代码，服务端的项目更是如此。
上面的场景在游戏业务中太常见了，但是并没有哪个组织哪个企业尝试去从上层给出一个框架或者库的解决方案。反观 Web 领域，他们的场景也游戏不太一样，但是会在另外的地方有难点。Web 最后是怎么做的？会有开源的解决方案出现，比如依赖数据库的强一致性性能瓶颈后会有人做消息队列，消息保证有且仅有一次消费，消息能持久化保证不丢失，大量的这些中间件，各种 Web 框架给开发者提供源源不断的动力。而且代码质量非常高，往往技术选型上升到范式，友好度，维护性这些上去了。
反观游戏界，以 java 为例，用个 netty 就算比较现代了，akka 的算是很前沿了，这些东西都不是为游戏界输出的，当然也不是游戏界产生的。老实说游戏界没产出啥开源方案。大家都是网络框架选型完了，数据库选型完了，剩下的就又开始在那个小圈子转来转去了，多少年都是在解决那些同样的问题。