分布式
分布式其他
1. 谈谈业务中使用分布式的场景
分布式是将一个业务拆分不同的子业务，分布在不同的机器上执行。有些人会认为分布式=集群。然而集群本意是指多台服务器几种在一起，实现同一业务，可以视为一台计算机。分布式的组织松散，不像集群有着极强的组织性，一台服务器宕机，其他的可以代替其进行功能处理，而分布式的每一个节点都完成不同的业务，一个节点宕机了这个业务就无法访问了。
分布式的每一个节点都可以用作集群，而集群却不一定是分布式。
分布式是在服务应用层随着用户量的增加，并发量增加，但项目难以承受如此巨大的并发请求而导致的性能瓶颈。而对于底层数据库层而言，随着业务的发展，数据库存储信息过多，多大，也会导致数据库压力变大，从而引起性能瓶颈。
分布式是对于以上的解决方案。我们可以综合使用分布式和集群来进行高并发高可用系统的开发。
参考：
《面试题：谈谈业务中使用分布式的场景》
《分布式和集群区别？什么是云计算平台？分布式的应用场景？》
2. Session 分布式方案
在集群/分布式环境下必须要考虑用户访问所产生的session如何处理。如果不做任何处理的话，如果用户两次访问请求分别被不同服务器处理，则会导致分别有两个session被创建，而且第二次无法通过session域获取可能需要的数据，这将会成为系统设计的致命缺陷。
因此在分布式系统中，我们必须通过一定的策略来确保一个session必须能够被不同的服务器获取或者一个用户的所有请求必须被同一台服务器处理。
- 粘性session
将用户锁定到某一服务器上。当一个服务器接收了用户第一次请求，则以后该用户所有请求都将由这台服务器处理。这种方案不需要对session做任何特殊处理但缺乏容错性：如果服务器故障，用户被迫转移到另一台服务器，或不同服务器实现不同功能，用户所请求的功能只能由另一台服务器实现时，都会导致session失效。此功能可以通过在Nginx配置而轻易达成。 - 服务器session复制
任何一个服务器上的session发生改变，该节点会把这个session的所有内容序列化，然后广播给其他节点而不管其他服务器需不需要session，以此来保证session同步。
该方案容错率高，各个服务器间的session更够实时响应。但会对网络负荷造成压力，如果session量大的话可能造成网络堵塞，拖慢服务器性能。此方案可通过tomcat开启集群后配置网络广播实现。 - session共享机制
使用分布式缓存方案例如memcached，redis。但要求其必须是集群。
此方案容错高，session实时响应。
使用相应的开源插件可以达成此方案。 - session持久化到数据库
使用一个数据库专门存储session信息以保证session的持久化。
此方案当服务器出现问题时，session不会丢失。但本身数据库的访问速度就是很多系统的业务场景，都应该降低查询数据库的次数，此方法会导致增加数据库的访问，当访问量很大时甚至会拖垮数据库。 - terracotta实现session复制
terracotta的基本原理是对于集群键共享的数据，当一个节点发生变化的时候，terracotta只把变化的部分发送给terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点。可以认为是第二种方案的优化。
此方案对网络的压力很小，也不比浪费CPU时间和内存进行大量的序列化操作。把这种集群间数据共享的机制应用在session同步上，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。
参考：
《【Linux运维-集群技术进阶】集群/分布式环境下5种session处理策略》
3. Session 分布式处理
我没分清楚此题跟上面那题有什么区别，请参见2题。
4. 分布式锁的应用场景、分布式锁的产生原因、基本概念
在分布式场景下很多情况都需要实现最终一致性。在设计远程上下文的领域事件的时候，为了保证最终一致性，在通过领域事件进行通讯的方式中，可以共享存储，做全局XA事务，也可以借助消息中间件，和采用分布式锁。
基于分布式锁的解决方案都是相较于持久化方案提供了高可用性，并且支持丰富化的使用场景。
参考：
《分布式锁》
5. 分布式锁的常见解决方案
- 数据库锁表
数据库锁能实现一个简单的避免共享资源被多个系统操作的情况，在并发量不高的情况下，数据库锁的性能时可以依赖的，而且由于数据库的数据具有持久化的特性，可以满足一般的应用需求。
但数据库锁实现智能是非阻塞锁，如果无法获得会返回失败，且没有过期时间，导致如果程序异常会无法释放锁，表将会被锁导致锁表情况产生。且这把锁无法重入而且无法解决数据库宕机的问题。如果宕机，会使整个应用无法工作。 - 缓存锁
使用缓存作为分布锁，性能非常强大，redis可以达到每秒100k的操作次数，足以满足绝大部分应用的锁定需求。
redis锁定的原理是利用setex命令，即只有在某个key不存在的情况下才能set成功该key，这就达到了多个进程并发去set同一个key，只有一个进程能够set成功。且redis自带expire功能可以让我们无需主动去产出锁。且在2.6.12版本之后，redis的set命令直接设置NX和EX属性，一个命令就能完成原子性的加锁和设计过期时间。
缓存锁的性能优异，但由于数据保存于内存，一旦缓存服务宕机，数据将丢失。 - 分布式缓存锁——Redlock
redis作者鉴于单点redis作为分布式锁的可能出现的锁数据丢失问题，提出了Redlock算法，该算法实现了比单一节点更安全、可靠的分布式锁管理（DLM）。
使用Redlock算法，可以保证在挂掉最多2个节点的时候，分布式锁服务仍然能工作，这相比之前的数据库锁和缓存锁大大提高了可用性，由于redis的高效性能，分布式缓存锁性能并不比数据库锁差。 - zookeeper
zookeeper实现了类似paxos协议，是一个拥有多个节点分布式协调服务。对zookeeper写入请求会转发到leader，leader写入完成，并同步到其他节点，直到所有节点都写入完成，才返回客户端写入成功。它支持watcher机制，这样实现阻塞锁，可以watch锁数据，等到数据被删除，zookeeper会通知客户端去重新竞争锁。zookeeper的数据也支持临时节点的概念，即客户端写入的数据是临时数据，在客户端宕机后，临时数据会被删除，这样就实现了锁的异常释放。使用这样的方式，就不需要给锁增加超时自动释放的特性了。
参考：
《分布式锁》
6. 分布式事务的常见解决方案
分布式事务的处理一直以来都是个难题。
- 2PC方案--强一致性
数据更新成功后，，任意时刻所有副本中的数据都是一致的，一般采用同步方式实现。
2PC的核心原理是通过提交分阶段和记日志的方式，记录下事务提交所处的阶段状态，在组件宕机重启后，可通过日志恢复事务提交的阶段状态，并在这个状态节点重试。 - eBay时间队列方案 -- 最终一致性
弱一致性地一种形式，数据更新成功后，系统不城虐立即可以返回最新新入的值，但是保证最终会返回上一次更新操作的值。
eBay事件队列是将需要分布式处理的任务通过消息或者日志的方式来异步执行，消息或日志可以存到本地文件、数据库或消息队列，再通过业务规则进行失败重试，它要求各服务的接口是幂等的。 - TCC（Try-Confirm-Cancel）补偿模式 -- 最终一致性
由服务 A、服务B、服务C、服务D 共同组成的一个微服务架构系统。服务A 需要依次调用服务B、服务C 和服务D 共同完成一个操作。当服务A 调用服务D 失败时，若要保证整个系统数据的一致性，就要对服务B 和服务C 的invoke 操作进行回滚，执行反向的revert 操作。回滚成功后，整个微服务系统是数据一致的。 - 缓存数据最终一致性
缓存（Redis 或者Memcached）通常被用在数据库前面，作为数据读取的缓冲，使得I/O 操作不至于直接落在数据库上。
7. 集群与负载均衡的算法与实现
负载均衡算法可以参考Nginx的负载均衡的策略。
8. 说说分库与分表设计
此题和第九题都请参见dataStorage\数据库.md的第十题。
9. 分库与分表带来的分布式困境与应对之策
