瓶颈在数据库，前面加个队列削峰就行。

其实没啥，就是别忘记释放内存就行了

JWT 如果是仅用于身份认证那是极好的，但用于比较复杂的后台管理系统就不太合适。如我司的后台权限高达数千项之多，如果都放在 jwt 字符串里面，那是要死人的节奏。

所以我司系统发给用户的 token 就是一个 base64 编码后 116 位长度的字符串。解码后就是：{"id":"b016b5a2bd0147c897246d376c79f668","secret":"a4fa0f2d7c65437da86e5efab2837824"}这样的简单结构。授权信息在服务端的 token 里面，服务端 token 存在 redis 上面。把一个 token 一分为二，就像古代的虎符。用户只要拿能够代表其身份的一半就行了，其他数据反正只需要在服务端验证身份之后才会用到，就不需要给用户了。

比较个字符串怎么实现时序攻击？要攻击的话拦截入参就啥都知道了，还要时序攻击做咩？

顶配 18 款 15 寸 MBP，风扇响的时间非常少，少到我都不记得上次响是什么时候。对了，mbp 我是用来写代码的。

对于攻击者来说，几乎所有的验证方法都会在高频调用这一招下失效。成功率低又如何，我可以提高频率到每秒攻击十万百万次，还是能够 1 秒钟轻松艹你千百次。

所以真正能有效降低攻击频率的，是限流或者是低频的验证，如谷歌 Authenticator 这种动态密码。强制让所有人都只能 1 分钟只能访问一次，那就随便你攻击了。

无中生友系列……必须是地摊啊，总理推荐的能有错吗。

@594duck 对的，禁止单表数据超过 500 万才是 MySQL 的正确的打开方式，而不是屁用没有的禁止使用 join 。

至于不懂怎么保持单表数据不超过 500 万的小白，我只想说要学会就自己想办法，不要只会无脑往数据库里面怼数据。

这种需求无脑布隆过滤器

有多个候选人挑花眼了吧。楼主可以多拿几个 offer 反制。

做基础架构要比做业务有更好的大局观，然后还要了解各种业务才能做好。没两把刷子的还是不要去趟这个浑水了，容易做成楼上说的客服。

楼上那些动不动就几亿数据的，你们手上真有几亿数据？

真有几亿数据的还不分表分库？怕是分表分库之余还要历史数据归档也要整起来了。因为你不把这些手段使出来，业务根本没法跑，哪怕你禁止 join 也没用，MySQL 单表上千万性能就跌得厉害。

另外，数据库不是给你们无脑存数据的，要想系统稳定高效就得好好学学数据库，无论是关系型数据库还是非关系型数据库。

某些人天天喊着技术技术，结果呢连简单了解下数据库都不乐意。。。别以为会写几句代码就是会编程了，做一个合格的程序员没那么简单。

楼主太天真，维护老项目多好的差事啊，活轻松不说，裁员的时候裁谁都不会裁你。你的领导真的很关照你了，但你的表现在领导看来就是不领情，领导伤心了。

还有，开发新项目提升技术？可别开玩笑了，写不同的 crud 哪来的机会提升技术。最能提升技术的，就是用新技术重写老项目，没有之一。

不 join 还用个吊毛的性能弱鸡的关系型数据库，直接上 MongoDB 不香吗？

如果业务需要关系模型来支撑的话，那就必须该 join 就 join 。如果查询语句 join 过多导致性能问题，应该反思的是数据结构是否合理，SQL 语句是否能够优化，该有的索引是否建立，而不是一刀切不许 join 。

mbp 我向来都是最高配+内存拉满，iPhone 就直接丐版，因为丐版就已经到位了……

一种是通过代理注册账号，操作上和自己注册几乎没什么区别。有些资源购买后代理会给你返现的，返现大概 20 个点差不多。
另一种是委托代理注册账号，打钱给代理，代理帮你购买资源，价格要比自己买便宜更多。

可以按导出需求做个小小的数仓，然后从数仓导出数据就不会影响到业务，而且导出速度也能提升到毫秒级。