你能做的事情还有很多，确认业务机器、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]

赞同 21 、29 、35L
缓存是用在数据层的，而不是接口层，你自己也感觉到了
其次也不能滥用，像复杂条件查询或是 join 查询等等，应该去优化索引和提高 mysql 硬件配置，然后考虑分表
不建议你在错误的方案下解决问题

a+b 一个 goroutine，cde 各一个 goroutine，主线程 waitgroup

非广告，极客时间，MySQL45 讲，挺好的
+1

询问客服 ×
提交工单 ×
百度搜索 ×
v2ex 发帖 √

主表直接 group by visitor_id 试试？
换个角度，多次访问只做 update，确保只存在一条记录，在业务上是否允许？