@zcf0508 类似。不过这里是一个支持订阅到自有平台的一款产品，结合其他功能，能够和 RSSHub 分别开来。

@hamsterbase 感谢关注，你做的这个很漂亮。正在开发的 App 打算做一些订阅功能，所以算作商业化吧。GitHub 给你仓库 star 了，有时间学习一下。

@mlhadoop 鼠标双击就会选中一个单词了（英文），接着就会弹出单词解释啦。

@mlhadoop 在主页最下边，有“通用”插件包下载，拖到浏览器窗口就可以自动安装了。

https://metword.co

做产品是这样的。一些功能，很多产品可能都有做，不过都是作为各自整体产品的一部分，每个产品整体上侧重点不同，因此显出区别来。

@shovo 很好的建议，感谢。

@masker 据我所知，notion 只能搜索文章第一段（文章预览）哦，MetWord 支持搜索全文的，而且像 V2EX 帖子，GitHub issues 评论或者 Hacker News 评论页面都可以正确索引的。

@safeall 有个别网站设置了 media-src csp ，不允许从第三方网站加载媒体，而且无法绕过。

@sankemao 好的，可以考虑，再收集下更多用户反馈。

感谢作者，我个人很喜欢。

很不错，star 了，有机会学习下源码。

不会。下次再提 PR 的时候接着用。

Zabbix

Apple Music: 正在同步云端资料库 — forever

/etc/hosts + ~/.ssh/config

如果你指的“灾难性”是指 Kafka 挂掉以后缓存过期的实效性的话，可以适当缩短缓存的存活时间，让它自动快速过期。

@mitu9527 多立即删除这一次就像是心理安慰，没大用处。Kafka 集群挂了，未消费并 commit 的消息是持久化的，集群恢复以后消息还在，有什么好怕的。

@mitu9527 不需要立即删除，可以完全避免掉双写的。异步消息几乎是实时的，而且是可重试的，采用 kafka consumer group 还可以多重订阅一个消息。

当然，采用这种方案会带来架构的改变和额外的维护成本。不过我个人的实践来看，这种架构非常灵活，省去了一些传统上需要用分布式事务或者双写带来的复杂性，维护一套 Kafka + connector 还是值得的。

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 的使用体验。