微服务篇

1 微服务之间的调用方式？

1. RPC
2. 消息队列

2 CAP理论，BASE理论

CAP理论：

1. 一致性：
   更新操作成功并返回到客户端，所有节点在同一时间的数据完全一致。
   2.可用性
   服务一直正常，可用
2. 分区容错性

CP和AP：分区容错使必须保证的，当发生网络分区时，若继续服务，那么强一致性和可用性只能2选1

Base理论：
对CAP一致性和可用性的权衡的结果。
核心：即使无法做到强一致性，但每一个应用可以根据自身业务特点，采用适当的方式来使系统达到最终的一致性。

基本可用
软状态
最终一致性

3 分布式id是什么？有哪些解决方案？

唯一的id对应数据。
分布式系统，可能会出现id冲突。有以下四种解决方案：

1. uuid，复杂度低，影响空间和性能
2. 单机数据库的自增主键，并发量大时，有性能限制。
3. redis，zookeeper生成id， 比如redis的自增id，zookeeper的顺序节点，对比单机mysql的自增id更快。
4. 雪花算法，直接算法解决，最优解。原理是某一个机器在某一毫秒对某一个数字自增，这种方式可以保证分布式架构的系统id唯一。

4 分布式锁的使用场景是什么？有哪些实现方案？

分布式架构中，多个线程处于不同的进程，在进行资源竞争时，利用ReentranLock，Synchronized无法控制只有一个线程同时操作一个资源。

1. redis：setnx，lua脚本，消费订阅机制实现。redis分布式锁的特点是高可用，保证AP。不可靠。
2. zookeeper：临时节点，顺序节点，watch机制实现。zookeeper分布式锁的特点是高一致性，保证CP。更可靠。

5 什么是ZAB协议？

ZAB协议是Zookeeper实现一致性的原子广播协议。

1. 领导者选举
2. 数据同步
3. 请求广播：leader节点收到写请求后，广播写请求，使得事务在其他节点执行。
   尽量强一致。

zk和eureka的区别？

zk：cp设计（强一致性）
目标是分布式的协调系统，用于资源的统一管理。
当leader节点crash后，需进行leader的选举，这个期间zk服务不可用。

eureka：ap设计（高可用）
目标是服务注册发现系统，专门用于微服务的服务发现注册。
Eureka多个节点挂掉也不影响正常使用，剩下的节点依然可以提供注册和查询的服务。如果Eureka客户端向某个Eureka服务注册时，发现连接失败，会自动切换到其他节点。只要有一台Eureka节点正常运行，就能保证可用性，只不过查询的信息可能不是最新的。

当Eureka的服务器发现85%以上的服务没有心跳时，认为自己的网络出现问题，不会从服务队列中删除失去失效的服务。

数据库表拆分后如何解决唯一的主键？

1. UUID：
   优点：简单，性能好
   缺点：没有顺序，没有业务含义，存在泄露mac地址的风险
2. 数据库主键：
   优点：简单，递增，业务可读性，
   缺点：强依赖数据库，存在性能瓶颈，业务泄露的风险。
3. redis，mongodb，zk等中间件：
   优点：稳定
   缺点：复杂
   4.雪花id

雪花算法的原理

0-41位时间戳-10位workid-12位序列号
优点：性能佳，递增，可根据业务场景数据库节点布置灵活调整bit位划分。
缺点：强依赖时间，如果时间回拨，可能导致重复id生成。

spring cloud有哪些常用组件？

1. Eureka：注册中心
2. Nacos：注册中心，配置中心
3. Consul：注册中心，配置中心
4. Spring cloud config：配置中心
5. Figen，openFigen：RPC调用
6. Kong：服务网关
7. Zuul：服务网关
8. Spring Cloud GateWay：服务网关
9. Ribbon：负载均衡
10. Spring Cloud Sleth：链路追踪
11. Zipkin：链路追踪
12. Seata：分布式事务
13. Dubbo：RPC调用
14. Sentinel：服务熔断
15. Hystrix：服务熔断