@lanlanye 我上面有个地方写得不对, 如果冷存储是实时写的话, 删数据直接删就可以了. 有一种例外情况: 如果一次性删除的数据量很大, 那确实得做个临时的软删除, 然后在后台执行实际的删除操作, 不然对数据库性能会有冲击.

@lanlanye 归档这项工作可以由两个子项构成. 一项是将数据写入冷存储, 另一项是从热存储中将数据删除.
这两个工作其实没有必要同时进行. 因为有事件日志或者事件流的存在, 所以写冷存储这一步是可以实时进行的, 启动一个消费者就行了. 从热存储删数据倒可以做成定时任务, 挑一个负载较低的时段分批删就不错.

我的核心论点是: 关系型数据库里面最好只存热数据, 这样能将不少问题在发生前就消灭掉.

@xhcarlin 你说得没错, 对于数据本身的各类约束, 在越靠近数据的地方做, 实现成本就越低, 可靠性也越高.

看之前帖子里还有几个人说软删除的问题. 这类问题明明有更好的解决方式.
软删除会导致大量不活跃的数据堆积在数据库里, 然后导致数据持续膨胀, 接着就得分库分表, 这实在是没事找事.

其实只要能老老实实把各种事件日志, 审计日志打到 logstore 里面, 等到需要恢复的时候重播下特定的事件就可以了.
只要做到关系型数据库里只存热数据, 不用的数据该删就删, 冷数据该归档就归档. 80% 场景是用不着分库分表的.

@hiro0729 没错，刚刚乱点也发现了 XD

刚才又自己捣鼓了一会儿，发现 Event Log 标签设置里有一条 Language Plugins Notifications ，Popup type 选 No popup ，再把 Log 也勾掉就可以了。

以前写 Java 的时候用过 RxJava 这样的函数式框架, 写的时候的确很爽, 但调试的时候却很痛苦.
感觉函数式编程用在客户端代码会比较发挥得来.

这个问题太泛泛了, 只有先明确 IM 的功能完备程度, 需要支持的水平扩展规模等实际问题之后才能合理估计性能, 不然容易陷入局部最优的窘境. 也可以先找 https://github.com/OpenIMSDK/Open-IM-Server 这类成熟的项目研究看看.

@eudore 只是记录 error 是不够的，应尽量在系统内消化错误。所以需要一种方式来标准化错误格式，这样就能传递和处理跨服务的 error 了。

@godlovesxcjtest 是这样的，由于服务之间传递错误需要一个固定的格式，所以这里采用的是 Google API design 里的建议格式。所以里面的 request_id 不是用来记录日志的，而是错误格式本身所定义的。

关于错误码，任意层级都是可以设置的，以最后设置的为准。如果是增加非结构化的错误信息可以直接用 fmt.Errorf()，如果是结构化错误信息就需要用 errors.Annotate() 了。

@godlovesxcjtest 谢谢评价。

这个库主要在微服务的场景下使用。这时候需要考虑到错误的传递，比如不同的 status code 和 http code ，以及不同的错误类型需要有不同的 payload 来描述错误细节，再如 request_id 这样的字段。

当然简单的用法也有，比如只附加 status code 而不加具体的 detail ，但这里为了演示就把所有的字段都加上了。

最后那段代码里有点疑问:

- select 里有 default 那什么情况下才能执行到定时器的 case?
- Stop() 后面的 <-timer1.C, 如果主线程正好在 Stop() 后先读了 C 里面的内容, if 是不是就一直阻塞了?

@lastree 我这里看大小写是正常的，不知道还有没有其他人也遇到显示问题。