简单点：先写数据库然后再发通知
搞复杂点：数据库时顺便记录下消息发送状态，然后在发送消息，同时更新消息状态，再加上消息异常重试机制，这样就能保障最终一致性了

@ilucio 生产上 drop column 风险很高，多余字段放着就好了，一般只有 DDL 无法更改字段类型时才需要考虑拉 DBA
rename 表

@ilucio 上面这个没打完就自动发了，重发一次。。

dba 操作就没事了，rename 的时候找一个

不仅仅是连接池的问题，首先排查占用 sql 连接池的原因，1 ）慢 SQL 2 ）数据库服务太拉胯了；然后在调整连接池参数，一般 100 个左右就够了，单个应用开太多链接也会造成数据库 server 的连接池的浪费

select * from ( select * from a where bcode in (11,22,33)) t left join c left join b on t.bcode=b.code
这样表的数据就小很多了

这么理解比较好

应该是 MIN(WCSSOURCE)导致的，只对 WCSSOURCE 字段加索引效果应该是一样的

软考评分真是玄学，案例自评 55+结果 45 ，最后也挂在论文上了

去考高级软件架构师~

我觉得最难的是每个 step 的可忽略、可重试、可跳过设计实现。。

这就是工作流系统的典型实现，最近刚写过一个，用了责任链+策略模式，把责任链换成模板模式也可以，看具体需求了。我觉得这个需求里最难的是每个 step 的

@est 以前 IOT 上部署 python 就是这么搞的

试下 sourcetrail

@dtgxx 关掉 mongodb 服务，将整个 mongdb 数据文件夹拷贝过去，删除 diagnostic.data 文件夹，然后把旧的 mongodb 配置拷贝过来，修改下数据文件路径，这样 mongodb 就可以启动了。这种方法不会改变压缩方式等其它配置，因为只修改了数据文件路径

我的意思是直接用拷贝文件夹的方式就行了，不需要使用 mongoinmport

复制数据的话直接拷贝文件夹也可以的