分布式系统中的一些问题
一. CAP理论，BASE理论?
CAP:
- C：强一致性，保证每一节点(微服务)统一时间点数据的完全一致
- A：可用性，整个系统是一直可用的,而且是正常响应时间。不允许出现用户访问失败的情况
- P：分区容错性，某一个节点或者网络分区发生故障时，整个系统还是可用的，对于用户来说没有影响
注意：CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。P一定要实现，所以就是CP和AP的权衡。
BASE:
- BA：基本可用，系统出现问题，用户的响应时间增加了，或者非核心功能不可用了。都是可以的。
- S：软状态，数据同步允许有延迟，这一段延迟的状态就是软状态。
- E：数据最终一致性，在经过一段时间的数据同步后，最终能达到一直就行，不要求实时。
总结：cap是最理想化的,base是对cap的一些理解,更加现实化,是对cap的妥协。
二. 负载均衡算法，类型?
算法:
- 轮询法；加权轮询法
- 随机法；加权随机法
- 源地址哈希法：根据客户端ip地址，通过哈希计算得到一个数值，对服务器列表进行取模，得到的结果就是要访问的服务器的序号。
- 可以保证同一个ip地址的客户，每次请求都会映射到指定的服务器.
- 最小连接数法：比较灵活和智能，比如A服务器有5个链接，B有3个，C没有链接。下次请求就会进入C服务器。
类型:
- DNS实现的负载均衡：访问一个域名，映射到不同的ip地址
- 硬件负载均衡：F5和A10
- 软件负载均衡： Nginx，HAproxy，LVS等
三.分布式架构下,session共享有什么方案?
- 使用jwt
- 使用cookie (有安全风险)
- 服务器之间进行session同步：保证每个服务器都有session信息，消耗比较大。
- ip绑定策略：比如使用Ngnix进行源地址哈希法的负载均衡，让每一个ip固定访问一个服务器， 但是这种就失去分布式的作用。
- 使用redis存储：是业界最广泛的。 可实现不同服务，不同平台(网页/app)，甚至不同语言的session共享。
四. 分布式id生成方案?
- UUID：时间戳+时钟序列(计数器)+唯一的IEEE机器识别码(比如网卡的MAC地址)
- 对数据库不友好，因为随机不连续。mysql的主键默认使用聚集索引，造成索引不连续
- 数据库自增：对于数据库集群模型，要设置不同的数据库起始值不同，但是步长(自增几)相同。
- Leaf-segment：(美团大众点评的)采用每次获取一个ID区间的方式。
- 比如一次和数据库的交互， 就请求到100个id，数据来了直接用。避免每次添加数据都请求一个id，增加了数据库的压力。 也是对数据库自增策略的一个优化。
- 雪花算法(最流行)
- snowflake是Twitter开源的分布式ID生成算法，结果是一个长度为64bit的long型的ID。
- 其核心思想是：41位时间戳+10位机器id+12位序列号+符号位(0)。 12bit作为毫秒内的流水号，就是说每个节点在每毫秒可以产生4096 个ID，并且是趋势递增的。
- 这样适合于Mysql的聚集索引，因为趋势递增。索引的连续性好。
- 缺点：依赖于时间戳，时间戳是根据机器的时间得到的。比如linux中，如果人为的进行时钟回拨，就可能造成id重复。
五.如何实现接口的幂等性?
接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,，不会因为多次点击而产生了副作用。比如注册，支付时，不会因为多次点击产生不正确的结果。
- mysql 的唯一索引：比如注册，设置账号唯一，多次插入时就不会成功。但是需要每次操作数据库，不好
- token机制：服务器在访问接口前就传给用户一个特定token并且保存在redis，访问接口带上该token， 判断是否是第一次，是的话允许操作，完成逻辑后删除token；不是的话不允许操作。
- redis的setnx命令：如图
- 版本控制：加乐观锁，对于update时常用。
- 状态控制：例如订单的状态有已支付，未支付，支付中，支付失败等。只有处于未支付的时候才允许修改为支付中
寄语：宝剑锋从磨砺出，梅花香自苦寒来