经典双写一致性。
这是参考方案之一。
1.写请求只删除缓存，不更新缓存。写请求先删除缓存，再更新数据。无论成功与否，写请求只会导致缓存失效，永不导致脏数据。

2.读请求更新缓存。读写请求高并发时，有可能导致写请求删除缓存，读请求紧接着更新了旧数据缓存，写请求再完成了数据更新，产生双写不一致。

3.读写串行化，适用于读多写少的场景。缓存有效时，读请求按一般流程处理。写请求发生时，缓存失效，同一 id 的并发的写请求和读请求进入同一队列(或同一加锁处理逻辑)，保证双写一致性。串行化时，可能会导致大量并发的读请求超时，所以要在数据实时性(准确)还是系统可用性做下取舍。

我猜如果要用传统 db，就用 map 保存字段-字段信息的结构，然后转 json 存数据库，这里要考虑的就是大的 map，存取时，序列化 /反序列化的效率。

上面写错了，是 unsubscribe

但问题是，冗余≠多余，冗余设计为了维护扩展，那是可行的。
如果真要较真，应该举证，根据业务需求的复杂度，认为绝大部分情况不需要在 tryAgain 中写额外逻辑，即 undescribe 的逻辑足够简单且能表达整个操作的意思，那就不需要该冗余。

看 hutool 的维护者对于 issue 的处理难免让人觉得有点功利主义。

平台=公开，不允许的怎么公开？

b 站搜尚硅谷的官方号。

建议开除 datagrip

敲码百遍，其义自见。记不住肯定就是敲得少了嘛。

一线品牌整机或显卡吧置顶帖。前者溢价买保障，后者真实性价比。其他的都不推荐。百度“整机烈士墙”，有！真！相！

@MiBAO #55 点击“感谢回复者”（在别人的回复的箭头的左侧，默认是隐藏的，鼠标移过去才会显示），❤️就会加 1 了。

另外银行还是 ibm 的老客户呢，db2 也不少。

oracle 比 mysql 强多了，功能丰富多了，但是解决问题有 2 种方案:
1.我希望应用服务的职责简单点，数据库的职责复杂点，数据库是无所不能的。
2.我希望应用服务的职责复杂点，数据库的职责简单点，数据库就是存储仓库。
这些东西你得有实际工作经验才能明白，比如传统项目和互联网项目，nosql，大数据等。

如果是让你在现有的公司项目里写，又没人带你，写不出来可以理解。毕竟国企项目，用的什么技术栈都不稀奇。

其实就是脚手架，那些框架基本带代码生成器，并且支持自定义模版。
所以其实最最最核心的需求是需要一套符合自己业务需求的代码生成器，而用这些框架稍微改下就好。

@shiguiyou #29 但是到后面履历会给找工作带来麻烦吧？

相比技术选型，我倒是觉得能否设计优化一下，不能快速返回，就把处理结果持久化，然后增加个拉取持久化结果的接口，提示用户查询耗时较长，可以先获取部分结果，让用户主动刷新。

天然对中文开源圈没好感，无意一杆子打死所有好的，只是这种低水平低素质的人太多了。

要么自带输入法。
要么通解，火绒弹窗拦截，之所以不用其他拦截是觉得火绒够安静。