关于分布式

关于分布式 一、什么是分布式? 一个系统,各组件分别部署在不同服务器。彼此通过网络通信和协调的系统。 可以指多个不同组件分布在网络上互相协作 也可以一个组件的多个副本组成集群,互相协作如同一个组件,比如数据存储服务中心为了数据不丢失而采取的多个服务备份冗余 分布式最早出现的目的首先是解决单点问题,避免单点故障,然后解决了性能问题 二、分布式和微服务的区别? 微服务并不一定是分布式系统(微服务中多个服务不一定部署在不同服务器,单机部署情况则不算是分布式) 分布式一定不是微服务 (分布式祖耀侧重服务的部署方式,微服务则是针对应用的一种服务拆分的架构) 三、分布式CAP原则 在设计一个分布式项目的时候会遇到三个特性: 一致性(Consistency):所有节点数据实时同步,读取始终返回最新值 可用性(Availability):每个请求必须得到响应(无论数据是否最新),高可用 分区容错(Partition Tolerance):分布式最基本也是必需要有的特性,系统在遇到某个节点或网络分区故障时,仍然能够对外提供服务 三者无法同时满足,最多只能实现其中两个,网络分区发生时,必须牺牲C或A ‌CP(牺牲可用性)‌:如ZooKeeper,确保数据强一致性但可能拒绝请求 ‌AP(牺牲一致性)‌:如Eureka,保证服务可用但允许数据短暂不一致 三、 BASE理论 BASE理论是分布式系统设计原则,BASE 是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency),核心思想是即使无法做到强一致性(CAP 的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性。 基本可用(Basically Available):分布式系统,在出现故障的时候,允许损失部分可用性。类似服务降级 软状态(Soft State):允许系统存在中间状态,而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。 最终一致性(Eventual Consistency):系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。 四、分布式事务及解决方案 分布式事务 本地事务依赖数据库本身提供的事务特性来实现, 但是在分布式环境下,可能会出现需要远程调用,比如: begin transaction; //1.本地数据库操作:张三减少金额 //2.远程调用:让李四增加金额 commit transation; 张三和李四的账户不在一个数据库中甚至不在一个应用系统里,实现转账事务需要通过远程调用,由于网络问题就会导致分布式事务问题。 分布式事务解决方案 2PC 2PC 即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase)、提交阶段(commit phase),2 是指两个阶段,P 是指准备阶段,C 是指提交阶段。偏向数据库 TCC TCC 是 Try、Confirm、Cancel 三个词语的缩写,TCC 要求每个分支事务实现三个操作:预处理 Try、确认 Confirm、撤销 Cancel。Try 操作做业务检查及资源预留,Confirm 做业务确认操作,Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的分支事务的 Try 操作,任何一个分支事务的Try操作执行失败,TM 将会发起所有分支事务的 Cancel 操作,若 Try 操作全部成功,TM 将会发起所有分支事务的 Confirm 操作,其中 Confirm/Cancel 操作若执行失败,TM 会进行重试。偏向代码

June 11, 2024 · 1 min · Leanku

分布式session

分布式session 在单体服务器的年代,Session 直接保存在服务器中,是没有问题的,而且实现起来很容易。 但是随着分布式架构的流行,单个服务器已经不能满足系统的需要了,通常都会把系统部署在多台服务器上,通过负载均衡把请求分发到其中的一台服务器上; 那么很有可能第一次请求访问的 A 服务器,创建了 Session ,但是第二次访问到了 B 服务器,这时就会出现取不到 Session 的情况; 于是,分布式架构中,Session 共享就成了一个很大的问题。 解决方案 1. session同步 思路:多个web-server之间相互同步session,这样每个web-server之间都包含全部的session 优点:web-server支持的功能,应用程序不需要修改代码 不足: 1.session的同步需要数据传输,占内网带宽,有时延。 2.所有web-server都包含所有session数据,数据量受内存限制,无法水平扩展。 3.主从架构固有的保证一致性会牺牲可用性的特定,但进行主从同步时,登陆的请求将被阻塞,显然不符合用户实际需求。 2. 客户端存储法 思路:服务端存储所有用户的session,内存占用较大,可以将session存储到浏览器cookie中 优点:服务端不需要存储 缺点: 1.每次http请求都携带session,占外网带宽 2.数据存储在端上,并在网络传输,存在泄漏、篡改、窃取等安全隐患 3.session存储的数据大小受cookie限制 “端存储”的方案虽然不常用,但确实是一种思路。 3. 反向代理hash一致性 思路:使用 Nginx (或其他复杂均衡软硬件)中的 IP 绑定策略,同一个 IP 只能在指定的同一个机器访问,但是这样做失去了负载均衡的意义,当挂掉一台服务器的时候,会影响一批用户的使用,风险很大; 反向代理层做逻辑处理 方案一:ip进行hash 反向代理层使用用户ip来做hash,以保证同一个ip的请求落在同一个web-server上. 方案二:含有业务属性的字段hash 反向代理使用http协议中的某些业务属性来做hash,例如sid,city_id,user_id等,能够更加灵活的实施hash策略,以保证同一个浏览器用户的请求落在同一个web-server(即不同的user_id对应不同的web-server). 总结:让专业的软件做专业的事情,反向代理就负责转发,尽量不要引入应用层业务属性,除非不得不这么做(例如,有时候多机房多活需要按照业务属性路由到不同机房的web-server)。 4. 后端统一集中存储(主流方案) 思路:将session存储在web-server后端的存储层,数据库或者缓存 优点: 1.没有安全隐患 2.可以水平扩展,数据库/缓存水平切分即可,可以存储较多的session。 3.web-server重启或者扩容都不会有session丢失 不足:增加了一次网络调用,并且需要修改应用代码。 对于db存储还是cache,个人推荐后者:session读取的频率会很高,数据库压力会比较大。 如果有session高可用需求,cache可以做高可用,但大部分情况下session可以丢失,一般也不需要考虑高可用。

April 21, 2024 · 1 min · Leanku

Redis分布式

Redis分布式 一、 Redis分布式概述 1. 什么是Redis分布式 Redis分布式是指将Redis数据分布到多个Redis节点上,通过集群方式提供更高性能、更大容量和更好可用性的解决方案。 1.2 为什么需要Redis分布式 数据量增长:单机内存容量有限 高并发需求:单机性能瓶颈 高可用性:避免单点故障 可扩展性:支持业务动态扩容 1.3 Redis分布式方案对比 方案 优点 缺点 使用场景 主从复制 部署简单,读写分离 写操作单点,故障需手动切换 读多写少,数据备份 Redis Sentinel 自动故障转移,高可用 配置复杂,扩容不便 生产环境高可用 Redis Cluster 数据分片,自动故障转移 客户端兼容性要求,迁移复杂 大数据量,高并发 二、 Redis分布式方案搭建 2.1 主从复制搭建 配置文件示例 主节点 (master.conf): port 6379 daemonize yes pidfile /var/run/redis_6379.pid logfile "/var/log/redis_6379.log" 从节点 (slave.conf): port 6380 daemonize yes pidfile /var/run/redis_6380.pid logfile "/var/log/redis_6380.log" slaveof 127.0.0.1 6379 启动命令 # 启动主节点 redis-server master.conf # 启动从节点 redis-server slave.conf 2.2 Redis Sentinel搭建 Sentinel配置文件...

March 12, 2024 · 3 min · Leanku