- 1.分布式id如何生成？
- 2.雪花算法了解过吗？
- 3.什么是CAP定理？
- 4.分布式事务了解过吗？
- 5.什么是二阶段提交（2PC）？什么是三阶段提交（3PC）？
- 6.TCC了解过吗？
- 7.Paxos算法了解过吗？
- 8.Zookeeper的Zab协议了解过吗？
- 9.知道什么是Gossip协议吗？
- 10.了解过哪些负载均衡算法？
- 11.负载均衡的实现方案有哪些？
- 12.正向代理和反向代理的区别
- 13.分布式 Session了解过吗？如何实现？
- 14.如何防止表单重复提交？
- 15.如何设计一个秒杀系统?
- 16.分布式系统的接口幂等性设计
- 17.如何保障请求执行顺序
- 18.BASE理论了解过吗？
- 19.SOA和微服务架构有哪些区别?
- 参考资料
详见：https://mp.weixin.qq.com/s/eakphQDWKrsUnIwTj8zMQA
雪花算法生成的是Long类型的ID，一个Long类型占8个字节，每个字节占8比特，也就是说一个Long类型占64个比特。 雪花ID组成结构：正数位（占1比特）+ 时间戳（占41比特）+ 机器ID（占5比特）+ 数据中心（占5比特）+ 自增值（占12比特），总共64比特组成的一个Long类型。 第一个bit位（1bit）：Java中long的最高位是符号位代表正负，正数是0，负数是1，一般生成ID都为正数，所以默认为0。 时间戳部分（41bit）：毫秒级的时间，不建议存当前时间戳，而是用（当前时间戳 - 固定开始时间戳）的差值，可以使产生的ID从更小的值开始；41位的时间戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年 工作机器id（10bit）：也被叫做workId，这个可以灵活配置，机房或者机器号组合都可以。 序列号部分（12bit），自增值支持同一毫秒内同一个节点可以生成4096个ID
任何分布式系统都无法同时满足一致性(consistency),可用性(availibity),分区容错性(partition tolerance)这三项,最多只可同时满足其中的两项。
涉及到多个数据库操作的事务即为分布式事务,目的是为保证分布式系统中的数据一致性.
二阶段提交2PC:第一步请求阶段通过协调者来统计表决结果,第二步执行表决后的结果,如果表决的结果是提交,那就提交执行,否则不执行提交.缺点是同步阻塞,而且万一协调者挂了就无法保证ACID.
三阶段提交3PC:在2PC的第一步拆分成了2步并且引入了超时机制,解决了2PC的痛点.第一步先向参与者发出一个信号,看看大家是否都能提交,如果可以就返回yes,否则返回no.第二步PreCommit阶段,预提交一下,如果参与者可以完成commit,就返回ack进确认,如果不能则放弃提交本次事务.第三步doCommit阶段,进行真正的事务提交.
try,commit,cancel的缩写,try阶段进行检测,commit提交执行,只要try阶段成功了commit就一定会被执行,cancel业务出现错误时执行,回滚事务,释放资源.
详见：https://blog.csdn.net/westbrookliu/article/details/99713365
详见：https://blog.csdn.net/liuchang19950703/article/details/111406622
详见：https://mp.weixin.qq.com/s/dW0I29Sw86lU0qHpxyhdmw
轮询（Round Robin） 轮询算法把每个请求轮流发送到每个服务器上。 该算法比较适合每个服务器的性能差不多的场景，如果有性能存在差异的情况下，那么性能较差的服务器可能无法承担多大的负载。
加权轮询（Weighted Round Robbin） 加权轮询是在轮询的基础上，根据服务器的性能差异，为服务器赋予一定的权值。
最少连接（least Connections） 由于每个请求的连接时间不一样，使用轮询或者加权轮询算法的话，可能会让一台服务器当前连接数过多，而另一台服务器的连接数过少，造成负载不均衡。最少连接算法就是将请求发送给当前最少连接数的服务器上。
加权最小连接（Weighted Least Connection） 在最小连接的基础上，根据服务器的性能为每台服务器分配权重，然后根据权重计算出每台服务器能处理的连接数。
随机算法（Random） 把请求随机发送到服务器上。和轮询算法类似，该算法比较适合服务器性能差不多的场景。
DNS 解析 使用 DNS 作为负载均衡器，会根据负载情况返回不同服务器的 IP 地址。大型网站基本使用了这种方式最为第一级负载均衡手段，然后在内部在第二级负载均衡。
修改 MAC 地址 使用 LVS（Linux Virtual Server）这种链路层负载均衡器，根据负载情况修改请求的 MAC 地址。
修改 IP 地址 在网络层修改请求的目的 IP 地址。
HTTP 重定向 HTTP 重定向负载均衡服务器收到 HTTP 请求之后会返回服务器的地址，并将该地址写入 HTTP 重定向响应中返回给浏览器，浏览器收到后再次发送请求。
正向代理：发生在客户端，是由用户主动发起的。比如翻墙，客户端通过主动访问代理服务器，让代理服务器获得需要的外网数据，然后转发回客户端。 反向代理：发生在服务器端，用户不知道发生了代理。
如果不做任何处理的话，用户将出现频繁登录的现象，比如集群中存在 A、B 两台服务器，用户在第一次访问网站时，Nginx 通过其负载均衡机制将用户请求转发到 A 服务器，这时 A 服务器就会给用户创建一个 Session。当用户第二次发送请求时，Nginx 将其负载均衡到 B 服务器，而这时候 B 服务器并不存在 Session，所以就会将用户踢到登录页面。这将大大降低用户体验度，导致用户的流失，这种情况是项目绝不应该出现的。
- 粘性 Session 原理 粘性 Session 是指将用户锁定到某一个服务器上，比如上面说的例子，用户第一次请求时，负载均衡器将用户的请求转发到了 A 服务器上，如果负载均衡器设置了粘性 Session 的话，那么用户以后的每次请求都会转发到 A 服务器上，相当于把用户和 A 服务器粘到了一块，这就是粘性 Session 机制。
优点 简单，不需要对 Session 做任何处理。
缺点 缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的 Session 信息都将失效。
适用场景 发生故障对客户产生的影响较小； 服务器发生故障是低概率事件。
- 服务器 Session 复制
原理 任何一个服务器上的 Session 发生改变，该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要 Session，以此来保证 Session 同步。
优点 可容错，各个服务器间 Session 能够实时响应。
缺点 会对网络负荷造成一定压力，如果 Session 量大的话可能会造成网络堵塞，拖慢服务器性能。
实现方式 设置 Tomcat 的 server.xml 开启 tomcat 集群功能。 在应用里增加信息：通知应用当前处于集群环境中，支持分布式，即在 web.xml 中添加 选项。
- Session 共享机制
使用分布式缓存方案比如 Memcached、Redis，但是要求 Memcached 或 Redis 必须是集群。 使用 Session 共享也分两种机制，两种情况如下：
3.1 粘性 Session 共享机制 和粘性 Session 一样，一个用户的 Session 会绑定到一个 Tomcat 上。Memcached 只是起到备份作用。
3.2 非粘性 Session 共享机制
原理 Tomcat 本身不存储 Session，而是存入 Memcached 中。Memcached 集群构建主从复制架构。
优点 可容错，Session 实时响应。 实现方式 用开源的 msm 插件解决 Tomcat 之间的 Session 共享：Memcached_Session_Manager（MSM）
- Session 持久化到数据库
原理 拿出一个数据库，专门用来存储 Session 信息。保证 Session 的持久化。
优点 服务器出现问题，Session 不会丢失。
缺点 如果网站的访问量很大，把 Session 存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。
- Terracotta 实现 Session 复制
原理 Terracotta 的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta 只把变化的部分发送给 Terracotta 服务器，然后由服务器把它转发给真正需要这个数据的节点。它是服务器 Session 复制的优化。
优点 这样对网络的压力就非常小，各个节点也不必浪费 CPU 时间和内存进行大量的序列化操作。把这种集群间数据共享的机制应用在 Session 同步上，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。
前端。每次点击后都要等X秒才能点击。 数据库添加唯一索引 服务器返回表单页面时，会先生成一个token保存于session或redis，当表单提交时候携带token，如果token一致，则执行后续，并将服务器中的token删除。
前端：在秒杀之前，按钮置灰，并且不给前端真正的请求地址。前端定时请求后端接口，如果到了秒杀时间，则返回给前端真正的地址，前端放开按钮，每次点击后都要等X秒才能点击。 服务器：服务器用nginx做集群、redis也做集群 限流：在秒杀之前，将秒杀数量的令牌存入到redis中，可以用list，每次来请求都去redis中取出令牌，如果获取到说明秒杀成功，然后去访问数据库下单，如果没有获取到，则说明商品卖完了。 消息中间件：如果秒杀数量比较多，例如上万十万，则秒杀成功之后，将成功的请求放入到mq或者kafka中间件中，再从消息队列中获取请求。 服务降级：为了以防万一，还是要做服务熔断降级。
唯一id。每次操作，都根据操作和内容生成唯一的id，在执行之前先判断id是否存在，如果不存在则执行后续操作，并且保存到数据库或者redis等。 服务端提供发送token的接口，业务调用接口前先获取token,然后调用业务接口请求时，把token携带过去,务器判断token是否存在redis中，存在表示第一次请求，可以继续执行业务，执行业务完成后，最后需要把redis中的token删除 建去重表。将业务中有唯一标识的字段保存到去重表，如果表中存在，则表示已经处理过了 版本控制。增加版本号，当版本号符合时，才能更新数据 状态控制。例如订单有状态已支付 未支付 支付中 支付失败，当处于未支付的时候才允许修改为支付中等
一般来说，从业务逻辑上最好设计系统不需要这种顺序的保证，因为一旦引入顺序性保障，会导致系统复杂度的上升，效率会降低，对于热点数据会压力过大等问题。 首先使用一致性hash负载均衡策略，将同一个id的请求都分发到同一个机器上面去处理，比如订单可以根据订单id。如果处理的机器上面是多线程处理的，可以引入内存队列去处理，将相同id的请求通过hash到同一个队列当中，一个队列只对应一个处理线程。 最好能将多个操作合并成一个操作。
BASE是 Basically Available (基本可用) Soft state(软状态) Eventually consistent(最终一致性)这几个单词的缩写,是从CAP理论发展而来的,其核心思想是:即使无法做到强一致性,但每个应用都可以根据自身特点,采取适当的方式来使系统达到最终一致性.
微服务是在SOA的基础上发展而来,从粒度上来说,微服务的粒度要比SOA更细. 微服务由于粒度更细,所以微服务架构的耦合度相对于SOA架构的耦合度更低. 微服务的服务规模相较于SOA一般要更大,所能承载的并发量也更高.
https://www.cnblogs.com/workstation-nigoudongma/p/9546801.html https://blog.csdn.net/zgsxhdzxl/article/details/104414475 https://blog.csdn.net/lovexiaotaozi/article/details/89713937