范安崇的博客

其他各种情况：正常、各种异常，都以 main lock 的情况，进而读取正确数据。根据上述介绍，可以发现， Percolator 对于异常是一种 lazy （懒）处理。这时， A 的值为 hello （ write 字段指示了当前数据是哪个版本）这里主要解释下，为啥这个阶段，只要 main lock 的提交成功即可。对于超时的情况，仅仅根据版本号，其实是不够的，因为数据可能在多台主机上。比较正规（严谨）的是版本号用全局时间戳代替，即版本号也是时间戳。任何一方写失败等，做回滚处理。

用哈希算法做玩家-聊天服的路由，是最轻量。但是对于聊天服失效、扩容、缩容需要做些而外的处理。这样机制，失效、扩容、缩容时，玩家可能会丢失 1 个心跳期间的消息，但是不重要可以接受。（如果感觉复杂，可以把路由信息所有聊天服同步、全量路由副本）类似还有公会聊天、好友群组聊天。

交易行功能可以划分为 3 块：以上功能实现，主要有 2 个难点：为了解决数据一致性问题，这里引入 + 机制：实现细节如下：Redis 中一个事务，至少包括以下信息：，至少包括以下信息：事务的核心在于提交事务是原子的。即提交的一瞬间，能保证所有数据同时更改生效这里设计提交事务的操作为：该操作可以成功提交事务的原因如下：本地进程，均加个定时器，定期检查：本地进程，均加个定时器，定期检查：缺点，是在事务提交成功后，再应用数据。因此数据可能出现负数解决方案 2 种：优点事务细节分解步骤如下：根据以上步骤，很容易设计

这样 2 个进程间传递 SQL 文还可以进一步适配具体项目，做调整。通常进程间传递数据，可以定义协议。因为是字符串 SQL 语句，因此可以方便的从一个进程传递到另外一个进程。有时，生成 SQL 文的进程和处理 SQL 文的进程，可能不是同一个。因为项目中使用 protobuf ，那么可以使用它，减少重复构造轮子。这里就涉及到如何高效的把 SQL 文从一个进程传递给另外一个进程。单步调试了下 go-sql-driver/mysql 的简易例子。结果，go-sql-driver/mysql 库也无。

方案二：每个服通过 Redis 共享 alarm 信息，自己处理去重。方案一：把告警信息打到 alarm 服，让 alarm 服去重处理。因为 alarm 去重逻辑很简单，方案一显得稍重，需要额外维护服务。粗暴的处理告警，通常会导致刷屏，进而麻木，最后起不到告警的作用。开发环境、生成环境，通常会有很多种告警，用来及时发现问题。这里设计一个简单的去重机制。