@echotpq 那没多少区别，redis 是有瓶颈的，关键在内存速度。达到瓶颈你增加配置也没用，只能分布式。

公司不诚信，不建议留。

最终订单只会在 12306 上面，只存在一个。你是因为使用第三方帮你抢票，并不一定是已支付到 12306 的状态。
估计飞猪等平台是以抢到票并且你在平台支付为最终反馈，而不是以平台再支付 12306 的订单回调作为反馈。
所以你这种情况会正常出现，给你个流程详解：你在两个平台抢票->平台同时刷抢票 API->抢票成功回调(问题在此，此回调同时被读取)->平台都返回抢票成功->两个平台订单锁定(12306 实际锁定一个订单)->你在两个平台里面都支付成功->两个平台返回支付成功给你->两个平台后台支付 12306 的订单->必定有一个支付失败但是不会及时通知你。最后两步是平台后台去做的，你最后得到的信息是倒数第三步。
所以结论就是平台有个支付失败的订单，后期应该可以退款给你。不要怀疑 12306 的系统，早就经过更严格的测试了

怎么可能一样，你 CPU 也是单线程，CPU 还得处理其他进程。

8000 看你在哪买，大运营商可能买来配置低一些。
如果是买小运营商的，大概配置可以支撑日均 UV5W 左右，QPS 只能撑几百。
高防一般会带一点，具体还要看你网站运营内容，不能一概而论。

给你个建议吧，用 Swoole Tracker 调试一下看看，到底哪里内存泄露了。完了给帖子做个结论。

微信啊，对接一下就行了

要么洗鼻，要么买喷雾。 没别的办法。。。

你写的代码问题，$redis->brpop 自动阻塞 60 秒，后面又 sleep10。另外$redis->brpop 无返回值你确定 empty 会判断为空吗？ brpop 超时后也是会返回一个列表的，这样你就是一直循环生成对象了。

两种可能，打新，内幕交易或者操纵市场。第一种不违法。
反正流水是经过你的卡，你随时可以查到。第二种违法，俗称马甲账号，规避监控。建议你可以在开户之后绑定微信，随时看到交易记录。

逗我呢？ 这种情况你觉得会出现吗？

JWT 本身就是作为跨域来使用的，你先去学习一下 JWT 原理，你连原理都没懂就分析是在浪费时间。
token 存入 cookie 是后端来交互的，你分别把 token 存在不同的域名 cookie 下就行了，后端获取到 cookie 再到单点登录服务器处理。。。 我字都不想打了，你还是去学习一下吧。
还有后面的知识，我觉得你应该经验不足。

jwt token 的方法因为是不同域所以 token 没法加在 cookie 里面，因为不是前后端分离，所以没法在每次请求的时候加在 header 里面???
这句话没一个地方说对了，你再把这两点理解清楚一下吧。

这个看每个厂的特征算法，因为一般取特征的时候眼部数量肯定比脸额头嘴下巴少，所以你会觉得影响小。口罩直接遮住了一半特征当然影响大。

1-2 年开发经验与上有冲突吧，现在本科有学 Python 的专业吗？有的话就定向找会好一点

我以为打开了知乎。。。
需要 DDOS 测试一下吗？