Friends don't let friends do dual writes.

更新完数据库紧接着更新缓存或者写入消息队列，这就是双写或者多写，总会有第一步成功了下一步失败的概率（比如网络抖动等原因），这时候就会造成数据不一致。

我个人的项目实践了一种事件驱动的异步架构，也就是 CDC （ change data capture ）架构，选型上使用的是 Debezium + Kafka connector ，当然 Java 生态的也可以用 Canal 替换 Debezium 。简单来说 Debezium 的工作就是监听数据库的写入变更（ pg 的 wal log 或 mysql 的 bin log ），为每条变更记录生成一条 Kafka message （包含变更记录的主键 id 等其他字段信息），通过 Kafka connector 自动写入到一个数据库表对应的 Kafka Topic 。采用这种架构处理缓存过期就很简单了。业务端只要更新数据库就可以，（避免了双写的问题），更新缓存的逻辑起一个线程或 goroutine 监听这个表对应的 Kafka topic ，拿到消息以后解析出主键 id ，然后 purge 掉对应记录的缓存。如果消费了这条消息以后 purge 缓存失败怎么办？有这种可能的。Kafka 的 message 有 commit 机制，purge 失败可以一直重试，当成功了以后再 commit 消息。虽然这种架构是异步的，不过得益于 Kafka 的良好吞吐性能，几乎可以做到 real-time 的使用体验。

真棒！感谢分享。

先在 goroutine 里启动任务，然后 Echo 启动不成功直接 panic.

> 请在标题中描述内容要点。如果一件事情在标题的长度内就已经可以说清楚，那就没有必要写正文了。

@zhouchijian vscode + Xcode 开发 app 😄

vscode 主要 remote 到 linux 笔记本不怎么吃内存（ docker 也跑在 Linux 上），就是 Xcode 模拟器一开 swap 会用很多，这时候有一点儿小卡。其它时候很丝滑。

这么说吧，过几年你出掉这个机器 16G 怕是不太好出（然而我个人用着 8G 的 M1 iMac 不亦乐乎）

好棒，支持这么多扩展不容易！占个楼，没选上也会购买。

变量自动取地址和指针自动解引用是在方法的*调用*阶段，为了方便所以加了这样的语法糖。
而案例中 return 值到 interface 变量，是在方法的*定义*阶段，可能这时候不让具体类型变量满足指针 receiver 的 interface ，为了强调吧。当然假如不是这种设计，像 op 期待的那样，返回值是具体类型，自动取地址以满足指针 recieve 的 interface ，实现上应该也是可以的，只不过设计者没有做这种选择。我个人还是觉得就是为了在方法的*定义*阶段强调返回值的正确性吧。

Anyway ，暴露指针而不是采用引用类型，可能是 Go 的缺点之一吧。（如果采用引用类型又可能会带来什么问题，我没有了解）。

@jindeq (粵語)偏爱，喜爱，喜欢 :)

好事儿。可能就像 Kotlin 和 Java 的关系吧。

一个 bug：

便签窗口关闭后，点击 dock 上的 app 图标无反应（无便签窗口弹出）。

感谢创造&分享。几个建议：

1. 可以设置使用标准字体吗？不太心水这几款手写体。
2. 可以设置窗口大小就好了，喜欢窄窄的长条状的便签，放边上不占空间。
3. 能调整透明度就更好啦。

文档很不错，star 了。

写 web 的话，echo 框架有集中处理错误的方式，比如加上 message 字段或者根据 accept header 返回不同的 content-type 数据。在业务 handler 里只需要 return error 就好了。

另外，同意楼上说的，方便的不一定是正确的。Go 的错误处理虽然还有优化空间，但在很多人看来这种方式起码是正确的。

耗尽的意思。比如 nginx -s reload 会开一个新线程接受新连接，待老线程把当前连接都处理完了（ drain ），老线程再退出。

楼上对 Last.fm 感兴趣的各位，Spotify 原生支持将播放记录同步到 Last.fm ，只需要 OAuth 授权一下。

if err != nil {
// handle err
}

就是屋外空气湿的原因，这两天不是下雨了嘛。我住是在阳面，很大一扇窗，屋里湿度也是 60 以上。

iOS 用过最好的天气 app 是新浪天气，完全免费无广告。能显示几分钟后下雨以及几分钟雨停。