@yellowmarlboro #4 数据库也是可以当作普通软件用的吧，mysql 什么针对特定场景优化配置其实内存消耗可以非常低的，容错了简单，本地库查挂了就再查一次主库就是了，再搞个监控解决了

@yellowmarlboro #4 其实既然都是备库了，sql 库无论 sql 执行效率和内存效率都是最高的了吧，你自己搞个内存计算的既不如数据库高效也不如数据库稳定，性能不够多搞几个备库节点就是了呗，网络消耗的其实无所谓了吧

更进一步其实可以直接在应用节点搞个备库就是了呗，或者用 sqlite 也行呗，没必要非要搞个内存执行 sql 吧

@realpg 首先合不合理是一回事，历史遗留问题为保持一致性不应该修改是另一回事，别说整个计算机体系里了，整个世界不合理的设计早就多如牛毛了，人家都告诉你 breaking change 还有啥好说的，所以啊就算你觉得应该有更好设计那现实的也是 featute 不是 bug ，你想修正它那也是在提新 featute 而不是提 bug ，接不接受那是别人的权利

@xxxyangyu #9 你这个是使用场景不匹配的问题吧，plc ，pxi 设备之所以这么设计协议估计就首先约定控制端在同一物理位置且通过可靠忘了连接，你非要弄到公网或者弱网下用，不单独添加设备侧得本地网关保证可靠性，显然是不能的吧

@XuanYuan 也许你用 openssl 连一下测试看看，估计就会看到发了 client hello 之后没啥反应了，好像一直有这个问题吧

@stinkytofu 长轮询每两分钟返回一次，websocket 也要差不多时间发送心跳，也就是数据量和解析复杂度差距，应该没有那么耗资源吧，用户量不大估计可以忽略不计了吧

干掉 redis 可以省成本不好么。。虽然大型站要做风控并不能做到完全不在服务器保存数据，但是能省一点是一点吧

其实也就是服务器保存还是客户端保存的问题，客户端存储中小型站少个依赖简单便宜性能好又无需考虑风控，再加上各种框架库支持完善又跨语言跨平台跨集群使用广自然了，生态好也是优势啊而且是大优势，但也没说 JWT 就是完美无敌的吧，中大型站嘛自然是啥都要，区分也就不大了

全服务不就是 vpn 么，各种服务工具一大堆

@guanhui07 #10 php 单引号\n 是不表示转义吧，所有就是单纯的两个字符\和 n ，所以和 java 不一样了

php 的 bode 为啥要 json_encode ，这肯定不一样了啊

可以把 id 存库，查询和管理迁移方便，数据确实还是存文件更好，想要速度多机并行化就是了，缓存也更容易做，还可以用 hbase 之类的分布式存储，oss 服务之类的，扩展能力安全性效率都更好

@jjx 事实 pypy 毛病太多不流行是并不好用，内存消耗大非常多，预热很慢，扩展支持有问题，而且想自己编译十分麻烦，在生产环境用过很长时间，收益并没有想的那么高，还是又切会 cpython 了，十分友好的内存消耗和扩展支持才是 python 的优势，放弃了才是脑子有病，支持干掉 gil 但前提是不大范围提升内存要求和扩展支持要求，否则意义真不大

参数校验既然不是错误为啥要写错误日志，空指针异常报错居然不是 bug 真是。。你们这测试真可有够严谨的，正常的应用不都是上线不允许有 errror 级别日志，否则监控系统直接报异常

error 级别日志输出一般应该包含两种，一是硬件或系统非预期异常，第二种就是不在设计业务流程的非预期异常，参数校验校验本来就属于业务流程一部分的而且也需要测试，所以应该属于符合业务流程且在预期内的异常，顶多算个 waring 吧

@isbase 以前那是支付宝内部 P0 故障，现在支付宝微信这种体量的再出这种直接工信部 P0 故障，你掂量掂量🤪

k8s 的话也许是 dns 解析问题

估计和两步验证那个密码差不多吧

千万不要低估你对不确定未来的恐惧