系统设计 + MySQL

Author: xbox1994

MD/数据库-MySQL.md

@@ -26,7 +26,34 @@ MyISAM相对简单所以在效率上要优于InnoDB。如果系统插入和查
 答：在xxx列上建立索引，因为索引是B+树顺序排列的，锁在下次查询的时候就会使用索引来查询到最大的值是哪个
 
 问：如何对分页进行优化？
-答：`SELECT * FROM big_table order by xx LIMIT 1000000,20`，这条语句会查询出1000020条的所有数据然后丢弃掉前1000000条，为了避免全表扫描的操作，在order by的列上加**索引**就能通过扫描索引来查询。但是这条语句会查询还是会扫描1000020条，还能改进成`select id from big_table where id >= 1000000 order by xx LIMIT 0,20`，用ID作为**过滤**条件将不需要查询的数据直接去除。
+答：
+
+```sql
+select * from table_name limit 10000,10
+```
+
+这句 SQL 的执行逻辑是：
+
+1. 从数据表中读取第N条数据添加到数据集中
+2. 重复第一步直到 N = 10000 + 10
+3. 根据 offset 抛弃前面 10000 条数
+4. 返回剩余的 10 条数据
+
+数据库的数据存储是随机的，使用 B+Tree， Hash 等方式组织索引。所以当你让数据库读取第 10001 条数据的时候，数据库就只能一条一条的去查去数
+
+最简单的方法是利用自增索引（假设为id）：
+
+```sql
+select * from table_name where (id >= 10000) limit 10
+```
+
+但思路是有局限性的，首先必须要有自增索引列，而且数据在逻辑上必须是连续的，其次，你还必须知道特征值。如此苛刻的要求，在实际应用中是不可能满足的
+
+好的方式是利用子查询把原来的基于user的搜索转化为基于主键（id）的搜索，主查询因为已经获得了准确的索引值，所以查询过程也相对较快：
+
+```sql
+select * from table_name inner join ( select id from table_name where (user = xxx) limit 10000,10) b using (id)
+```
 
 #### 最左前缀匹配原则
 在mysql建立联合索引时会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。mysql会一直向右匹配直到遇到范围查询（>/</between/like）就停止后面的匹配，比如a=3 and b=4 and c>5 and d=6，如果建立（a,b,c,d）联合索引，d就用不到索引，如果建立（a,b,d,c）则都能用到索引。

MD/系统设计-高并发抢红包.md

@@ -0,0 +1,28 @@
+## 题目
+总共有10亿个红包，在某个时间一起来抢红包，如何设计
+
+## 分析
+主要考察的是如何设计高并发系统，但实际上存在一定变通处理方式，不一定全在技术上
+
+通常在考虑系统QPS时，应当按业务上的极限QPS作为系统必须承担的QPS设计，比如10亿个红包，因为用户量巨大，极限QPS是可能是10亿
+
+但是一般来说几万QPS已经是比较高的并发了，就需要比较大的集群和高并发架构来处理了，所以不可能真正实现10亿的并发架构，而是通过一些变通的方法来处理，比如在业务上做一些处理规避掉部分流量
+
+但尽可能地需要实现高并发架构，思路是将大部分流量拦截在系统承载能力低的模块之前
+
+## 回答
+#### 业务上适当规避
+在相应法律法规、规章制度、活动说明、用户体验允许的情况下，可以做以下处理
+
+1. 根据某些规则对部分用户直接返回没抢到。比如有些用户曾经被系统识别为恶意用户、垃圾用户、僵尸用户，直接告诉用户已经抢完
+2. 分散不同客户端打开活动入口的时间。比如将1秒内的10亿流量分散到10秒，那么平均每秒只有1亿了
+3. 增加客户端入口点击门槛。比如需要手机摇一摇、画一个图案才能触发抢红包的接口
+
+#### 技术上硬核抗压
+网关是会接触实打实10亿流量的地方，也是拦截掉最多无效流量的地方，同理，缓存也是
+
+1. 限流策略。比如在压力测试中我们测到系统1亿QPS达到了极限，那么超过的部分直接返回已经抢完，通过Nginx的lua脚本可以查redis看到QPS数据从而可以动态调节
+2. 作弊拦截。通过对UA、IP规则直接将抢红包的作弊流量拦截掉
+3. 异步削峰。对Redis中的红包预减数量，立即返回抢红包成功请用户等待，然后把发送消息发给消息队列，进行流量的第二次削峰，让后台服务慢慢处理
+4. 服务逻辑。比如业务逻辑是使用事务控制对数据库的创建红包记录，减红包数量的操作，那么创建操作要放到减数量操作之前，从而避免减数量update的行锁持有时间
+5. 机器配置。当然是服务器机器配置约高越好，数据库配置越猛越好，高并发抢红包主要是CPU的负载较高，要选择偏向CPU性能的机器

README.md

@@ -49,8 +49,9 @@
 ### 项目举例
 * [秒杀架构](https://github.com/xbox1994/2018-Java-Interview/blob/master/MD/秒杀架构.md)
 ### 系统设计
-* [系统设计题答题套路](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#%E5%A6%82%E4%BD%95%E5%A4%84%E7%90%86%E4%B8%80%E4%B8%AA%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E7%9A%84%E9%9D%A2%E8%AF%95%E9%A2%98)
-* [在AWS上扩展到数百万用户的系统](https://www.wangtianyi.top/blog/2019/03/06/zai-awsshang-kuo-zhan-dao-shu-bai-mo-yong-hu-de-xi-tong/?utm_source=github&utm_medium=github)
-* [从面试者角度设计一个系统设计题](http://www.wangtianyi.top/blog/2018/08/31/xi-tong-she-ji-mian-shi-ti-zong-he-kao-cha-mian-shi-zhe-de-da-zhao/?utm_source=github&utm_medium=github)
+* [系统设计-高并发抢红包](https://github.com/xbox1994/2018-Java-Interview/blob/master/MD/系统设计-高并发抢红包.md)
+* [系统设计-答题套路](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#%E5%A6%82%E4%BD%95%E5%A4%84%E7%90%86%E4%B8%80%E4%B8%AA%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E7%9A%84%E9%9D%A2%E8%AF%95%E9%A2%98)
+* [系统设计-在AWS上扩展到数百万用户的系统](https://www.wangtianyi.top/blog/2019/03/06/zai-awsshang-kuo-zhan-dao-shu-bai-mo-yong-hu-de-xi-tong/?utm_source=github&utm_medium=github)
+* [系统设计-从面试者角度设计一个系统设计题](http://www.wangtianyi.top/blog/2018/08/31/xi-tong-she-ji-mian-shi-ti-zong-he-kao-cha-mian-shi-zhe-de-da-zhao/?utm_source=github&utm_medium=github)
 
 欢迎光临[我的博客](http://www.wangtianyi.top/?utm_source=github&utm_medium=github)，发现更多技术资源~