某网友：高并发：使用场景少，价格高昂，好比屠龙之技，龙就那么几条，还都差不多被砍死了。
随着相关资料的泛滥，将来它会是一门“出入江湖必备的手艺”，如太祖长拳一般的泛滥，不值一文。
1、mysql
1）1主多从，多主多从
2）sql优化：explain
3）谢绝join语句
某研发，执行1个select联表查询，cpu卡了2秒，线上报警
2、缓存
1）本地cache
2）缓存：redis
3）es集群
有点缓存的意思~
搜索，排序，计算
4）预加载数据
3、mq消息队列
1）削峰填谷，充分利用
2）异步处理
3）拒绝分布式事务，也不太可能强一致性分布式事务
4）业务模式的优化：业务逻辑梳理
5）本地事务+mq
try{
makeOrder();
sendMq();
}catch(Exception e){
...
}
mq是一个服务，也可能挂掉。
try{
makeOrder();
saveLocalLog();
}catch(Exception e){
...
}
for(Log log : logList){
sendMq();
}
4、RPC接口：响应时间，很快，100ms以内，20ms以内
多线程：同时查询多个rpc
多个业务包装到1个rpc返回，而不是分多次查询
RPC接口，要合理拆分，订单-支付紧密放在一起；商品-广告等展示的放一起。
5、避免查询时计算
1个商品，多少人评价
6、批量查询
谢绝for循环查询，redis批量查询，mget
7、开关，降级
618各种开关，缓存，永久缓存
8、堆机器，32台机器
几百万用户，几十万用户，并发访问
扩容，缩容
9、只查询必要的字段，只返回必要的字段
10、代码本身的优化
工具代码，选择性能好的，Fastjson...
11、部署在相同的机房
同1个人的请求，映射到同1个机器~
12、批量查询 替代 单个查询
for循环+单个查询，禁止
redis，mget批量查询
13、重复点击
前端 按钮禁止，后端 防重？表单提交，带token
14、业务流程拆分，简化。
用户操作，简化。
比如，员工花名册，全部资料批量保存。改为 1个模块，单独保存。甚至1个模块的，学习经历，分条操作。
转账处理，给个 loading提示~支付，用户手动点击 "已支付"
100、几千万上亿用户
套路完全一样吗？还需要做更多的技术优化吗，除了堆机器。。。
