场景设计1-12 场景设计1-12

1.如果让你设计mysql高可用方案的话，你会优先考虑哪些方面？
- 一、MySQL高可用架构应该考虑什么？
- 二、你认为应该如何设计?
- 三、mysql高可用方案
2.抖音评论系统怎么设计，如果加入好友关系呢？
3.怎么设计一个短链地址？要考虑跨机房部署问题
- 短链301和302区别？
4.统计用户在线最大峰值和人数，要精确到秒
5.微博点赞设计分析
6.如何“扛住100亿次请求”的春晚红包系统
7.你怎么防止优惠券有人重复刷？
8.分布式系统一致性
9.让你设计一个web框架，你要怎么设计，说一下步骤
10.orm的设计思路
11.怎么搞一个并发服务程序？
12.常用的设计模式

1.如果让你设计mysql高可用方案的话，你会优先考虑哪些方面？一、MySQL高可用架构应该考虑什么？

对业务的了解，需要考虑业务对数据库一致性要求的敏感程度，切换过程中是否有事务会丢失
对于基础设施的了解，需要了解基础设施的高可用的架构。例如单网线，单电源等情况
对于数据库故障时间掌握，业务方最多能容忍时间范围，因为高可用切换导致的应用不可用时间
需要了解主流的高可用的优缺点：例如 MHA/PXC/MGR 等。
考虑多IDC多副本分布，支持IDC级别节点全部掉线后，业务可以切到另一个机房

二、你认为应该如何设计?

基础层和基础运维部门配合，了解和避免网络/ 硬盘/ 电源等是否会出现单点故障
应用层和应用开发同学配合，在关键业务中记录SQL日志，可以做到即使切换，出现丢事务的情况，也可以通过手工补的方式保证数据一致性，例如：交易型的业务引入状态机，事务状态，应对数据库切换后事务重做
业务层了解自己的应用，根据不同的应用制定合理的高可用策略。
单机多实例环境及基于虚拟机或容器的设计不能分布在同一台物理机上。
最终大招在数据库不可用，可以把已提交的事务先存储到队列或者其他位置，等数据库恢复，重新应用

三、mysql高可用方案

第一种：一对一。小型第二种：一对多。中型。所有从master复制到node,master压力大第三种：一对一对多。一个主对一个从，一个从对多个从。分担读压力，相对安全

2.抖音评论系统怎么设计，如果加入好友关系呢？

评论为树状结构，层层嵌套，每个评论下面挂着若干子评论评论两种方案：方案一：单表设计，每个评论都有一个parent_id指向父评论方案二：分表设计，评论为一张表，子评论为一张表人际关系可以概况成以下四种: 1.关注我的 2.我关注的 3.互相关注的 4.互不关注的

3.怎么设计一个短链地址？要考虑跨机房部署问题

考虑跨机房部署：因为雪花算法生成id，根据时间生成。可能存在机器时钟回拨的问题，导致id重复方案一：无需考虑跨机房部署，hash算法，问题：hash冲突利用MurmurHash非加密哈希，比md5快十几倍。长链做 MurmurHash 计算，得到的哈希值为 3002604296，于是我们现在得到的短链为固定短链域名+哈希值 = www.baidu/1760305916import "fmt" import "github.com/spaolacci/murmur3"func main() { b := murmur3.Sum32WithSeed([]byte("www.baidu/abcdd.xxxx.com"),0x1234ABCD) fmt.Println(b) //3929151817 }如何缩短域名？ MurmurHash之后的数字为10进制，可以把数字转成62进制 www.baidu/4hUjSp方案二：发号器。来一个链接发一个号。跨机房的话，redis k-v存起来。校验。或者布隆过滤器，还是会hash冲突。解决方法： 1.用Redis做自增id生成器，性能高，但要考虑持久性的问题； 2.雪花算法做成一个服务，调用即可

短链301和302区别？

301，代表永久重定向，也就是说第一次请求拿到长链接后，下次浏览器再去请求短链的话，不会向短网址服务器请求了，而是直接从浏览器的缓存里拿，这样在 server 层面就无法获取到短网址的点击数了，如果这个链接刚好是某个活动的链接，也就无法分析此活动的效果。所以我们一般不采用 301。302，代表临时重定向，也就是说每次去请求短链都会去请求短网址服务器（除非响应中用 Cache-Control 或 Expired 暗示浏览器缓存）,这样就便于 server 统计点击数，所以虽然用 302 会给 server 增加一点压力，但在数据异常重要的今天，这点代码是值得的，所以推荐使用 302。

4.统计用户在线最大峰值和人数，要精确到秒

使用redis有序集合：上线+1，下线-1 //当前在线人数 rdb.ZIncrBy("onlineUsers",1,"count") // 人数自增+1 rdb.ZIncrBy("onlineUsers",-1,"count") // 人数自减-1整理需求：如果需要知道用户在线时间，及在线时间段人数,存时间戳 // 上线 err := rdb.Do("ZADD", "online", 1644375460, "user1") if err != nil { fmt.Println(err) } // 离线 err := rdb.Do("ZADD", "offline", 1644375460, "user1") if err != nil { fmt.Println(err) } 这样可以根据工作日，及时间段来知道用户在线的情况

5.微博点赞设计分析

1.用户点赞，本地统计，先保证自己立马看到变化 2.点赞事件发送至消息中心，kafka或者mq等。user_id，给某个微博id点赞 3.事件流处理，试试增量统计到redis，定时同步到mysql,或者es。或者时序性数据库tsdb

6.如何“扛住100亿次请求”的春晚红包系统

QPS：Queries per second 每秒的请求数目。 PPS：Packets per second 每秒数据包数目。摇红包：客户端发出一个摇红包的请求，如果系统有红包就会返回，用户获得红包。发红包：产生一个红包里面含有一定金额，红包指定数个用户，每个用户会收到红包信息，用户可以发送拆红包的请求，获取其中的部分金额。通过文章我们可以了解到接入服务器638台，服务上限大概是14.3亿用户，所以单机负载的用户上限大概是14.3亿/638台=228万用户/台。但是目前中国肯定不会有14亿用户同时在线，2016年微信用户大概是8亿，月活在5.4 亿左右。所以在2015年春节期间，虽然使用的用户会很多，但是同时在线肯定不到5.4亿。| 服务器数量一共有638台服务器，按照正常运维设计，我相信所有服务器不会完全上线，会有一定的硬件冗余，来防止突发硬件故障。假设一共有600台接入服务器。| 单机需要支持的负载数每台服务器支持的用户数：5.4亿/600 = 90万。也就是平均单机支持90万用户。如果真实情况比90万更多，则模拟的情况可能会有偏差，但是我认为QPS在这个实验中更重要。| 单机峰值QPS 文章中明确表示为1400万QPS。这个数值是非常高的，但是因为有600台服务器存在，所以单机的QPS为 1400万/600= 约为2.3万QPS，文章曾经提及系统可以支持4000万QPS，那么系统的QPS 至少要到4000万/600 = 约为 6.6万, 这个数值大约是目前的3倍，短期来看并不会被触及。但是我相信应该做过相应的压力测试。| 发放红包文中提到系统以5万个每秒的下发速度，那么单机每秒下发速度50000/600＝83个/秒，也就是单机系统应该保证每秒以83个的速度下发即可。最后整体看一下 100亿次摇红包这个需求，假设它是均匀地发生在春节联欢晚会的4个小时里，那么服务器的QPS 应该是10000000000/600/3600/4.0=1157。也就是单机每秒1000多次，这个数值其实并不高。如果完全由峰值速度1400万消化 10000000000/(1400*10000) = 714秒，也就是说只需要峰值坚持11分钟，就可以完成所有的请求。可见互联网产品的一个特点就是峰值非常高，持续时间并不会很长。| 总结从单台服务器看，它需要满足下面一些条件： ① 支持至少100万连接用户。 ② 每秒至少能处理2.3万的QPS，这里我们把目标定得更高一些，分别设定到了3万和6万 ③ 摇红包：支持每秒83个的速度下发放红包，也就是说每秒有2.3万次摇红包的请求，其中83个请求能摇到红包，其余的2.29万次请求会知道自己没摇到。当然客户端在收到红包以后，也需要确保客户端和服务器两边的红包数目和红包内的金额要一致。因为没有支付模块，所以我们也把要求提高一倍，达到200个红包每秒的分发速度。

7.你怎么防止优惠券有人重复刷？