RMI
RPC
CAP 定理
CAP 定理对分布式数据存储系统的特性进行高度抽象，提炼成了3个维度：
Consistency一致性, 每一次读取操作，要么系统返回最新的数据写入值（无论读取到哪一个数据节点），要么返回系统错误。Availability可用性, 每一次读取操作都能获得系统的返回，但不保证返回的是最新的数据写入值。Partition Tolerance分区容错性，当数据节点之间发生网络分区（包括网络丢包、连接中断阻塞等），系统仍然要继续工作。
这其中的底层逻辑是：分布式数据存储各节点之间通过网络连接，在运行期间不可避免存在网络分区的风险。
保证分区容错性，就是当发生网络分区异常时，整个系统仍然运行并继续工作，这时候提供的服务维度只可能在 Consistency 和 Availability 中保证一项。- 确保一致性，牺牲可用性。
系统会通过内部策略，自动修复集群，最终确保 Consistency 声明的强一致性。在自动修复完成之前，外部请求会返回系统出错或者超时。 - 确保可用性，牺牲一致性。
系统在自动修复集群期间，没有达成数据一致性的各节点仍会对外及时响应，确保 Availability 声明的高可用性。
狭义上来讲，CAP 定理中 Consistency 是忽略数据复制的网络延迟的，即：假设数据复制是瞬间完成，并且系统马上对外提供数据读取。
广义上，达成 Consistency 的网络延迟是可以接受的，不算网络分区，即使延迟了几分钟。
如果想要将网络延迟的影响加入到数据分布式的架构讨论中，可以参照 CAP 定理的延伸 PACELC 理论：
PAC 各字母同 CAP 理论， E (Else) 仅是连接词，L (latency) 、C (consistency)。意思就是，当没有出现网络分区、系统正常运行时，低延时（低于数据达成一致所需的平均延时水平） 和 数据一致性，二者需要选择其一，不能同时保证。
比如，MongoDB 集群的就是典型的 PA/EC 系统：在出现网络分区时，MongoDB 集群优先保证可用性，数据可能不是最新；在集群正常状态下，优先保证数据一致性。
BASE 原则
CAP 定理在应用系统开发中的一种解决方案。Basically Available 基本可用Soft state 软状态Eventually consistent 最终一致性
当应用无法做到强一致性时，每个应用可以根据自身的业务特点，采用适当的方式来使得系统达到最终一致性。
RAFT 共识算法
SOA
分布式系统
《分布式系统原理与范型》里总结：
分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像是单个相关系统。
从物理结构上来看，多台计算机资源通过计算机网络技术相连接，达成构建同一个系统的目的，这个计算机网络就叫做分布式系统。
相对的, 使用单一的计算机来构建系统的，这个单处理器系统就叫做集中式系统。
从系统架构的历史进程来看，从最早的纵向分层式架构，通过使用数据库服务、中间件服务等，将系统构建中一些通用的职责被代理到独立的计算资源上 —— 就已经是分布式系统了。
再到横向高可用架构的复制集、数据分片、集群架构等，又到现在的根据业务类型和职责划分的面向服务化、微服务架构等，都是分布式系统的范畴。
只不过对于当前 Java 应用开发来，提到分布式架构，主要讨论的点多是涉及面向服务化、微服务架构这方面，其次是纵向分层式架构。
Java应用 分布式系统带来的优缺点
优点
- 通过服务拆分实现了单一职责原则，带来了更好的封装性、扩展性、边界隔离
业务上
单一业务高内聚于一个服务中，当有业务变更时，仅需要修改、检查业务对应的服务即可，不会带来辐射式代码修改的成本，或者需求冲突造成需求很难实现的问题；
当系统面临外部业务环境的适应性挑战时，服务具有的高扩展性，可以更好地支持系统外部引进的业务变化和创新；
同时，由于服务边界的存在，当前系统运行中不涉及变更的其他服务，依然保持线上运行，降低了缺陷风险和验证成本。数据上
现在的应用服务，基于用户量和数据量的增长，很难仅使用一台数据库服务器就完成所有的数据存储与读写，相比于迁移到新型分布式数据库，
服务拆分将存储了不同领域字段的大表，根据业务域拆分成多个小表，从数据列的维度上解决了数据库的负载和压力问题。管理上
服务拆分与组织/团队划分相匹配，可以减少系统需求的不确定性、知识消耗和沟通的成本、降低研发时长、实现快速发布等。
- 通过服务化 + 云原生平台，带来了运算容量的弹性
- 构建初期不需要预估和预制高容量资源，可以根据线上资源的占用情况，进行后置资源扩容。
- 针对不同服务间的资源利用率，更有针对性地对处于资源瓶颈的服务进行扩容，避免了整体资源扩容带来的浪费。
同时由于服务划分了核心域、支撑域、通用域，不同的服务可以根据业务情况，选取不同的上线时间，最终可以达成业务的快速推出、反馈和验证。
提高了应用的健壮性和高可用性
纵向架构上，通过使用专业的分布式缓存、文件托管、消息队列、数据库等各类型中间件产品服务，降低了开发人力成本的同时，提升了开发质量和应用的健壮性。
横向架构上，服务的拆分和独立发布，以及服务实例集的使用，保障了应用整体的可用性 —— 不会因为一个服务的问题，造成整个应用的不可用。
缺点
- 技术运营能力的挑战
- 服务间集成的挑战
- 服务状态和数据分片的问题
比如，分布式任务调度、消息消费等等。 - 诊断和可视化的问题
比如，动态调用链、traceID、日志等等。 - 性能问题
- 安全问题
等等
总的来说，分布式系统带来了很多好处，同时也带来了不少的技术能力挑战和成本。
分布式定时任务
解决的数据分片问题
quartz
elastic-job
xxl-job
session
无状态
cookie id + session 下沉
数据全局唯一ID
雪花算法
