专业技能
1.分布式服务
- 为什么要做分布式服务
首先分析之前的系统架构及其存在的问题：单一系统在大容量、高并发、业务耦合、业务快速发展、系统演进迭代方面存在问题 - 分布式服务应该怎么做
1.原则：
无状态化（即使有，也要将状态封装在小范围内，避免影响横向扩展）
2.向2个方向扩展：
横向和纵向。横向解决系统的容量问题，同时对业务系统的拆分又能是业务领域知识专门化，有利于系统稳定性。纵向解决系统的灵活性和复杂性。同时业务进行纵向拆分，能够解决业务的逻辑复杂性，支持业务的快速扩展。
3.要有相关的支撑体系
分布式配置中心、分布式消息系统、分布式缓存、分布式数据存储
4.解决分布式的典型问题
通过以上的支撑体系，来解决典型问题，如 集群管理、共享锁、队列管理等问题
5.典型的分布式集群的设计思路
master-slave模式：如主从复制，双主+主从。示例：tair 如何解决扩容和数据一致性的。（扩容通过bucket的转移，容灾通过bucket的副本机制和配置更新时的版本控制）
无对等设计：利用gossip协议。（谣言协议，形象点说就是：说的人多了，就成了真的了。。。）
2.分布式缓存
- 了解哪些
使用过的有tair和redis，对redis了解的多一些 - redis都有哪些了解
1.数据结构，典型的如skiplist
2.线程模型：
单线程。风险点：大数据的操作容易造成阻塞
3.持久化
RDB。风险点：save会阻塞服务，bgsave不会阻塞服务（用的子进程+写时复制）。
AOF。记录命令的方式。可进行重写来缩减体积。
4.集群故障发现
gossip协议。多数人说某台机器有问题，就是有问题，就下掉该master
5.故障转移
epoch机制。slave发起选举，每轮epoch只能投一票。投不出结果就再来一轮epoch
6.缓存雪崩
避免同时过期、双缓存机制
7.缓存穿透
穿透后加互斥锁再访问数据库、布隆过滤器来判断是否是正常请求。
8.集群复制 TODO
hash槽，moved，ask
9.大key
对于集合类型的，拆分成多个key；禁止批量获取1000个以上的key
10.热点key
key分段+multi get、key做多个副本（针对小容量key）、服务本地缓存
11.线上问题
大key，热点key - 优势劣势
1.优势 纯内存速度快，数据结构支持应用场景多、
2.劣势 容量小
3.分布式任务
分布式调度
1.任务分发模式。由任务自己控制源数据的获取。优点是并行度高。
2.数据分发模式。任务系统抽取源数据，分发到任务。任务设计
1.规范
6个阶段：任务配置、任务执行、结果通知、业务监控、异常挂牌、异常重跑
3个级别：强制、推荐、参考
21子项：
任务配置：执行时间窗口、执行时长、任务依赖
任务执行：依赖校验、异常隔离、接口重试、可终止。。
异常重跑：为什么用java任务，而不用大数据处理
1.复杂性。业务逻辑复杂，很难处理。
2.成本。比如依赖各方的服务，而数据层是业务隔离的，但是java服务接口是现成的。
3.效率。
4.质量。高并发
多机分片+多线程、控制数据库写入速率防止主从延迟、外部输入数据查询如果串行查询太慢，考虑分片并行查询、任务结果同步到缓存数据一致性
数据源的flag校验、对账、幂等、重跑修复、异常重试、异常监控分布式
任务防并发执行（考勤）、分布式调度分片
4. MQ
介绍
特性：分布式的（topic分区且副本机制），pull模型（消费者维护消费进度，可回溯），分区内的有序性，无中心的控制机制（zk选举controller，进行集群管理，如分片）。集群
数据一致性
多种ack模式消息顺序性
offset机制。每条生产的消息都会被分配一个offset，其在分区内是唯一的，顺序的。offset不会跨越分区。所以消费者通过记录offset并顺序消费消息，来达到消息顺序性日志压缩
首先，在特定场景中，消费者只关心key对应的最新value。所以kafka启动子线程压缩日志，只保留最新的valueISR
同步的副本的集合。由leader副本维护。如果同步的消息滞后，就会被剔除。被剔除的不能被选择为leader。定期删除旧消息的策略
1.根据消息的保留时间 2.topic下消息的大小-
高并发
- topic分区。主副本负责读写，flower副本只负责同步容灾。
2.批量发送
3.数据存储，不在cache中，而是落入磁盘，且利用了顺序写入的高性能
4.IO：zero-copy
- topic分区。主副本负责读写，flower副本只负责同步容灾。
高可用
分布式集群负载均衡
1.生产者通过指定算法发送到不同分区
2.不同分区在不同broker上有副本。主副本负责读写
3.zk负责信息维护和更新为什么用（优点）
缺点是什么
