这种模糊查询，mysql 还是放弃吧，用 es

企业微信，个人可以注册企业微信，而且不用验证(不验证会有部分功能限制，但消息通知无限制)

JSON 序列化的 CPU 消耗还是很可观的，就如二楼所述，调用频率高真的会吃很高的 CPU

@chenqh 四楼的第二个链接就是文档，修改方式就是 upstream 添加 keepalive，以及 location 添加 proxy_http_version 1.1 和 proxy_set_header Connection ""就行。注意是这几个同时配置后才起效，缺一个都不行。

nginx -> server 默认的 http 负载均衡是 TCP 短连接，需要一些额外的配置才能设置成 HTTP 长连接。

有质量的建议通过熟人推荐，网上找到符合要求的很难

日本那边服务器上线要请巫女去开光，撒盐辟邪

这里说的就是 COW 过程中，原内存的一个内存页(默认 4K)被修改后，会发生中断然后复制出这个内存页的副本。极端情况下，如果 COW 过程中每个内存页都被修改，那么就会出现内存翻倍的情况。

数据库地址和账号密码的密文从配置中心读取，本地配置文件存放机密的密钥。
这样关键参数密文和密钥分开来放，另外数据库访问也做了 ip 白名单机制，这样除非是权限很高的内鬼，基本不担心数据库安全问题。

@zzkde 常见的是 Trans Log 和 Double Write 组合，数据更新时先添加 Trans Log，如果 Trans Log 写入失败则操作失败，每一条 Trans Log 都有完整校验，应用重启恢复读取 Trans Log 时完整校验没过 的 log 直接忽略。
然后数据写入通过 Double Write 方式，Double Write 是写两次，如果是第二次写失败可以通过第一次写的数据恢复；如果是第一次写失败，则可以通过 Trans Log 和原本的数据副本恢复。

程序应该自己保证数据落盘后文件完整性，就算写入中途突然断电中断导致数据页损坏，也可以通过应用本身的逻辑处理，或恢复成正确的旧数据，或接着断电前继续写新数据，而不会出现数据错乱的情况。

你这个其实是在问数据落盘的方案，现在的主流方式有：
1. Double Write
2. Shadow Paging
3. Trans Log
4. 每次全量写(Redis 的 RDB)

es 快速入门的话，中华石杉的 es 培训课挺不错的，或者买两本书慢慢啃

proxifier 、sstap，推荐 proxifier，自定义很强

sharding proxy

全靠脑子