分布式幂等性如何设计？
在高并发的场景里，一般需要对插入、更新进行幂等处理，意味这多次同样的请求，只有完成一次。
查询和删除不存在幂等说法，查询多次都是没有问题的，第一次删除、后面再次删除，返回的也是0，也是成功的。
-
token 方案，生成唯一的
-
添加分布式锁
-
唯一索引以及去重表
说说你对分布式事务的了解？
可以从 4 个点进行说明：场景、事务ACID、分布式理论CAP以及解决方案
-
场景：存在多个服务，每个服务操作库，都必须保证同时成功，否则全部失败。
-
ACID: 分布式服务部署的情况，需要考虑所有设计到的服务的事务加在一起，保证ACID。
-
CAP 理论：介绍下 CAP。
-
方案：可采用 Seata，消息队列加本地事务表，事务消息，最大努力通知方案，tcc
什么是 2 阶段提交协议？ 2pc
流程：第一阶段询问各个事务数据源是否准备好，第二阶段才真正将数据提交给数据源。适用于数据强一致性要求很高的场景、经理保证数据强一致性，不能100%保证，但是对性能影响较大，不适合高并发高性能场景。
遇到的问题： - 性能问题，所有的参与者处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。 - 可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。 - 数据一致性问题： 在第二阶段，有可能存在提交指令未执行问题，导致数据不一致。
对流程的优化： 实际使用：seata、tcc
什么是补偿事务？
针对每个操作，都要注册一个与其对应的确认和补偿操作。TCC就是采用补偿机制。
如何用消息队列实现分布式事务的？
通过消息队列，异步执行不同服务，保证最终一致性，也即BASE理论，保证每个服务都是本地事务。给用户响应够快、需要考虑补偿机制。
分布式 ID 生成有几种方案？
-
UUID：本地生成、简单、性能好、没有冲突风险，但是长度过长、无序且不可读，查询效率低
-
数据库自增ID: 数据库设置为自增，设置不同的步长，优点是实现简单、id有序，但是步长依赖于数据库数量，不方便数据库扩展。
-
批量生成ID：
-
redis生成ID：通过自增命令
-
雪花算法：1个符号位41位时间戳10位机器位12位序列号，共64位，高性能、按时间有序，一般不会碰状态，需要独立开发部署，百度、美团Leaf
常见的负载均衡算法有那些？
-
轮询均衡算法：适合服务器硬件都相同，一个个来。
-
加权轮询算法：按照权重不同来分发，基于配置。
-
随机轮询算法：
-
最少连接：记录每个服务正在处理的连接数，给最少连接的服务器上。
-
原地址散列：根据来源ip进行hash，只要地址不变，后面所有的请求，都是同一个节点处理，有利于session信息的维护。
什么是计数器（固定窗口）算法？
指定时间周期内，累加访问的次数，达到设定的阈值，触发限流策略。存在临界问题，比如在设在1分钟限定100，在59秒来了60个，第二分钟10秒又来了60个， 在这段时间，请求数量超过了100。
什么是滑动窗口算法？
为了解决固定窗口的缺点。在时间周期内进行分段，每个小的时间窗口内固定处理一定的请求，窗口随着时间走并删除过期的时间窗口，保证窗口内的请求数量不超过阈值，分得越细，越平滑。
什么是漏桶算法？
有恒定的流出速度，不管流入的速度有多快，流出的速度始终不变。类似于队列。缺点是，短时间大流量，处理不了。
什么是令牌桶算法？
增加一个固定大小的容器，也就是令牌桶，系统恒定的速率生成令牌，并放入桶中。请求来了，如果能获取到令牌则可以执行。
数据库如何处理大数据量？
分区、分库分表、主从架构读写分离。
什么是CAP理论？
-
C: consistency,一致性，数据在多个副本中保持一致
-
A: avaliable，可用性
-
P: partition,分区容错性。
在分布式系统中，必须满足P，也即分区容错性，如果不存在分区故障，那么AC都是成立的，当P满足时，A和C是互斥的，只能保证一个。
什么是 BASE 理论？
由于CAP理论中C和A无法同时满足，则提出BASE理论，保证基本可用、能保证最终一致性，不需要实时保证系统数据的强一致性。 实际中产品的可用性比强一致性更重要。
什么是可靠消息最终一致性方案？
允许数据在业务中出现短暂的不一致状态。