[26章]Java主流分布式解决方案多场景设计与实战

 Java主流分布式解决方案多场景设计与实战课程，计划26章，同步更新中。 随着互联网数据井喷式的发展，分布式技术应运而生。分布式因其高性能、高可用、高扩展的特点，成为微服务项目的基石。本课程针对分布式六大主流问题进行多方案对比解析，多场景实战讲解，让你深度掌握分布式原理和实战。 《Java主流分布式解决方案多场景设计与实战》分别从源码、手撸框架、实战演练等多个方面进行多维度深入讲解，让你轻松掌握分布式各种解决方案，掌握分布式解决方案的设计和架构能力，跻身分布式高手行列。 分布式基础 1、集群、分布式、SOA、微服务的概念及区别 集群：不同服务器部署同一套应用服务对外提供访问，实现服务的负载均衡或者互备(热备，主从等)，指同一种组件的多个实例，形成的逻辑上的整体。单个节点可以提供完整服务。集群是物理形态 分布式：服务的不同模块部署在不同的服务器上，单个节点不能提供完整服务，需要多节点协调提供服务(也可以是相同组件部署在不同节点、但节点间通过交换信息协作提供服务)，分布式强调的是工作方式 SOA：面向服务的架构，一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。 微服务：在 SOA 上做的升华，微服务架构强调的一个重点是业务需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。 单体应用升级成分布式应用，绝对不仅仅是由技术上可以解决的，不是技术OK就OK了，你会dubbo了，你会springclud了就可以保证迁移成分布式的，这一点一定要明白要认可。这些问题解决涉及业务部门及整个技术部门（开发、测试、 运维 ）协商与工作标准的制定。而且在升级过程中也不是一次性升级的，如果一次性升级的只会【SI】的惨。 业务相关问题暂不做讨论，如何和业务部门进行友好的协商，如何将单体应用迁移成为分布式，每个公司不同的业务，不同的环境，这里就不讨论了。技术架构上应该要清楚自己的职责是，如何通过技术手段把业务波动降至最低、开发成本最低、实施风险最低。 要解决这些问题的前提之一就是要对 分布式架构 有整体的认知，不是你会个分布式框架，会个RPC框架就搞的定的。相信举上边的例子大家应该是深有感触的。 是在实践过程中基于CAP理论演化而来的，基本可用，软状态，最终一致性 基本可用：是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。即保证核心可用 软状态：指系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延迟 最终一致性：所有数据副本经过一定时间后，最终能够达到一致的状态 核心思想：既然无法做到强一致性，但每个应用都可以跟据自身业务特点，采用适当的方式来使系统达到最终一致性，也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或不一致时，仍需要保持系统整体基本可用。 这只是Java中一些流行的分布式计算框架的简要介绍。根据具体需求和场景，还有其他框架可供选择。 Apache Hadoop：一个用于分布式存储和并行处理大数据集的开源框架。它包括Hadoop分布式文件系统（HDFS）和MapReduce计算模型。 Apache Spark：一个快速、通用的大规模数据处理框架。它支持内存计算，可以在磁盘和内存中同时进行数据处理和分析。 Apache Flink：一个流处理和批处理的开源平台，支持低延迟的、高吞吐量的分布式数据处理。 Apache Storm：一个实时数据处理框架，可用于分布式流处理。它支持可靠性、可扩展性和容错性，并保证数据的实时处理。 Apache Samza：一个用于流处理的分布式计算框架，支持有状态的流处理，可以与Apache Kafka集成。 Apache Beam：一个用于批处理和流处理的统一编程模型，支持多种分布式计算框架，如Apache Flink、Apache Spark和Google Cloud Dataflow等。 Spring Cloud Data Flow：一个用于构建和运行数据微服务的框架，支持各种分布式计算框架和数据处理工具。 Hazelcast：一个开源的内存数据网格平台，提供分布式数据存储和计算能力，可用于构建分布式系统和应用 【watch机制】一种基于事件的监听机制，可以让客户端对ZK上的节点和事件进行监听。 【临时节点】ZK上的一种特殊节点，它们在创建它们的客户端会话结束时会被自动删除。 在Zookeeper分布式锁服务中，watch机制和临时节点通常会一起使用。 通过Zookeeper的临时节点和watch机制，可以实现分布式锁的获取、释放和超时释放。 将锁的锁定状态存储在Zookeeper节点上，并通过Zookeeper的watch机制来实现锁的竞争和通知。 Zookeeper的watch机制和临时节点是实现分布式锁服务的重要机制，它利用了Zookeeper的分布式协调和通知机制，可以有效地实现多个进程或线程之间的互斥访问和同步。 当一个进程或线程想要获取锁时，它会在Zookeeper上创建一个临时顺序节点，并设置一个watch，并等待其他进程或线程释放锁。当锁被释放时，Zookeeper会通知等待的进程或线程，它们就可以获取锁了。当等待的进程或线程收到通知后，它们可以检查临时节点是否存在 如果存在，就说明有其他进程或线程持有了锁，自己还需要继续等待； 如果不存在，就说明锁已经被释放了，自己可以获取锁了。 基于Redis实现缓存 3.1搭建环境 3.1.1 添加核心依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>3.1.2 配置Redis@Configuration public class RedisConfig { @Autowired private RedisTemplate redisTemplate; //序列化设置一下 @PostConstruct public void setRedisTemplate() { redisTemplate.setKeySerializer(new StringRedisSerializer()); redisTemplate.setValueSerializer(new JdkSerializationRedisSerializer()); } }