最佳解决方案：redis

dns 轮询解析呢

喜欢直角完整屏，除了 se2 和索尼，有其他推荐吗

@mingtdlb 只是打开$$不一定走代理，还要确认工作模式，如果是 PAC，会有一个域名列表，包含在内的才走代理，其余直连；全局模式是无脑走代理。切换到全局模式试一下

研究下为什么上网慢？我怀疑是网站使用的某个第三方字体或脚本，没在 gfwlist 中，打开 F12 看看吧

你能做的事情还有很多，确认业务机器、redis 、mysql 的负载和带宽，单独编写接口做压力测试，尽可能多收集信息，再做思考

dns 的结果中不是全部 ip 都能直连，走代理吧

1.雪花算法：毫秒时间戳+集群号+机器号+进程号+自增序号
这里最关键的是进程常驻，需要 swoole/workerman 插件
2.额外写一个单实例部署的 id 生成器，加锁单线程运行，性能没有 1 好

上面要求？兄弟这种不合理的要求一定要据理力争啊，到时候查询扛不住再分库分表你不是白干了

@wuzhizuiguo 数据不准的原因是什么呢？开启事务和订单行锁，一般不会出现并发异常

二阶构建 只 copy 可执行程序 不会暴露源码

门店表加 total 字段，订单完成时同步增加，加好索引

@mitu9527 抱歉对 REST 不是很了解，抛开定义不谈，业务接口不可能无状态对吧，你不能让用户干什么都提交账号密码。下一步就是客户端保存 sessionId 和完整加密数据之间的博弈了，所以我觉得无状态是怎么定义的不重要，讨论最佳安全策略是最重要的。如果一定要讨论，我认为是 REST 本身设计就是无状态的，每个请求各自独立，不像 tcp 或是 NAT 那样需要依赖前次请求保存的状态；所谓状态是作为 REST 的用户在业务层面加上去的，跟协议本身其实无关。

有时间不如研究会话安全

我一般不会让前端直接指定需要哪些字段，要么全给（ QPS 要求不高时），要么定义几个场景，只让前端传一个场景参数，再根据场景拼接 sql 语句

一般 IO 为主的事务，语言性能占比很低，主要看网络环境

@hubahuba 同讨厌摸摸党

var that = this;
想起抖 Y 一个段子，蓝骑士送达外卖后指着屏幕对开发小哥说，这里加个 that，让它等于 this，然后下面就有权限访问了
该不会。。。[doge]