就用户信息这个 case, 不需要 ttl.
如果内存占用问不是问题, 建议用 string.
减少内存是你的头号问题, 考虑用 hash, key 的 overhead 更少.
hash 问题是如果以后迁移到 redis cluster, 所有 key 会在一个 slot 里, 分布不均匀

比如 http2 的 multiplexing , 在同一个 tcp connection 上跑多个 stream, 好处是减少了 latency(只需要一次连接建立), 坏处是单 connection 用不上多核, 很注重吞吐量的场景还需要在这之上实现一个线程池.

来问这问题就很奇怪, 能做到多少收益率只有你自己知道, 需要多少钱能覆盖生活支出也只有你自己知道, 两个一算就知道需要多少钱了, 问别人干什么

其实互联网业务一般是不会这么实现的, 要么程序完全无状态, 本地不存储任何东西, 带状态的程序要么数据 sharding 到多个节点上去, 要么就是单节点存储.

你得说说具体的业务, 就算在单机上, 多个进程访问同一个文件也是有问题的(并发控制, 一致性...)

多个 pod 同时挂载同一个 pv 需要底下的具体实现支持 multiple access mode, https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes

写傻了, 这种用 sonarqube 扫一下都能直接检查出来的.

话说 null 放前面是从 C 里带来的习惯, C 里 if (a=1) {} 能编译过的, 但逻辑是不对的.

楼上阅读理解都有问题吧，lz 不是禁止小孩看电视， 是要纠正凑太近的习惯

指数调整５个点都没到,就不行了, 18 年连跌 11 个月....这一波挺好的, 洗洗那些借钱买基的, 不然后面更惨

以为是楼主, 忘了 @lewis89

README 里有个连接讲原理. 其实就是 nginx 那套, spawn 一个新的子进程加载 elf binary, 复制 fd, 接管新流量, 老的进程会等待一个 graceful timeout 的时间把已接收的请求处理完, 你是消息队列消费者的话就要确保 task 能在这个时间内被处理完否则会被强制 kill. 和 k8s 还是有区别的, k8s 是在 kube-proxy 那层完成的流量切换, 没这么 tricky, 功能更强(可以实现红绿部署).

你说兼容栈帧那套单进程内热更新我很确定 go 是没有的,这个需要语言 runtime 支持, 印象里只有 erlang 支持, 而且限制性很大, 好处也就是能保留内存缓存.

chrome 里右键 inspect, 在 console 上对应元素上再右键 Copy -> Copy XPath