谈谈业务中使⽤分布式的场景.
1. 谈谈业务中使⽤分布式的场景.
⾸先, 需要连接系统为什么使⽤分布式.
随着互联⽹的发展, 传统的单体项⽬的性能瓶颈越发凸显, 性能瓶颈可能存在于⼀下⼏个⽅⾯:
应⽤服务层: 随着⽤户量的增加, 并发量增加, 单体项⽬难以承受如此之⼤的并发请求导致的性能瓶颈.
底层数据库层: 随着业务的发展, 数据库的压⼒也越来越⼤, 导致的性能瓶颈.
场景1: 应⽤系统集的Session共享.
应⽤系统集最简单的就是服务器集, ⽐如: Tomcat集. 应⽤系统集的时候, ⽐较凸显问题的就是Session共享, Session共享我们⼀是可以通过服务器插件去解决, 另⼀种也可以通过Redis等中间件解决( ⼀般采⽤Redis中间件, 使⽤服务器插件复制的话 将Session实时同步到每⼀个服务器上, 这样只能⽀持Session数量⽐较少的情况, 使⽤Redis中间件存储的话, 性能⽐较⾼, ⽽且稳定性也更好. ).
场景2: 应⽤系统的服务拆分.
服务化拆分, 是⽬前⽐较⽕热的⼀种⽅式. 现在都在说微服务. 通过对传统项⽬进⾏服务化拆分, 达到服务独⽴解耦, 单服务⼜可以横向扩容. 服务化拆分遇到的经典问题就是分布式事务问题. ⽬前, ⽐较常⽤的分布式事务解决⽅案有⼏种: 消息最终⼀致性, TCC补偿性事务等.
场景3: 底层数据库的压⼒分摊
如果系统的性能压⼒出现在数据库我们就可以采⽤读写分离, 分库分表等⽅案进⾏解决.
2. Session分布式⽅案
这⾥只介绍常⽤的两种.
2.1 基于Cookie的Session共享
将⽤户的session加密序列化之后, 以Cookie的⽅式保存在⽹站的根域名之下, 当⽤户访问所有⼆级域名的时候, 留恋其会传递所有匹配的根域名的Cookie信息, 这样实现了⽤户Cookie化Session的多服务共享. 此⽅案能够节省⼤量的服务器资源, 缺点是存储的信息长度将会受到http协议限制, ⽽且⼀个站点只能保存⼤约20条Cookie, ⽽且每次请求的时候都会带上session, 这样的话会造成⼀定的⽹络带宽浪费.
2.2 基于Redis的Session共享存储
这些键值对⾮关系型数据库有较⾼的性能, 可以轻松打到2000qps, 内置的过期机制正好满⾜Session的时效性特征.
在单独的服务器或者是服务器集上使⽤缓存技术, 使⽤Redis存储Session数据, ⼏种管理所有的Session, Redis可以做⾼可⽤集, 所有的Web服务器都从这个存储介质中读取相应的Session, 实现Session共享.
优点: 可靠性⾼, 在遇到性能瓶颈的时候可以横向扩展.
缺点: 实现略微复杂.
适⽤场景: Web服务器⽐较多, 可⽤性要求很⾼的状态.
可⽤⽅案: 开源⽅案Spring Session, 也可以⾃⼰实现.
3. 分布式锁的场景和实现.
使⽤场景
⾸先, 我们看这样⼀个场景, 客户下单的时候, 我们调⽤库存中⼼进⾏减库存, 那么我们的⼀般操作就是;
update store set num=${num} where id = ${id}
这种通过设置库存⽅式的修改, 我们知道在并发量⽐较⾼的时候回存在数据库的丢失更新, 如果A,B两个事物, 查询出来的库存都是5, a下了三个单⼦吧库存改为2, b下了⼀个单⼦将库存改为4, 这个时候出现了a回覆盖b的更新. 最终结果出现错误, 剩余库存为2.
这个时候我们需要采取CAS乐观锁去解决这个问题.
这⾥的CAS不需要考虑ABA问题, 因为即使这个时候加了库存, 中间发⽣了变化, 但是对于最终结果是不会产⽣影响的.
update store set num = ${num} where id = ${id} and num = ${query_num}
这个是只更新⼀个表, 如果牵扯到多个表呢, 我们希望和这个单⼦关联的所有的表同⼀时间只能被⼀个线程来处理更新, 多个线程按照不同的顺序去更新同⼀个单⼦关联的不同数据的时候, 出现死锁的概率⽐较⼤. 如果是分布式项⽬的话, 我们需要保证多线程多进程同时只能有⼀个进⾏的⼀个线程去处理, 这个时候我们就需要⽤到分布式锁. 分布式锁的实现⽅式有很多种, 我们今天分别通过,Zookeeper, Redis以及Tair的实现逻辑.
Zookeeper实现
获取锁
现有⼀个锁根节点, lockRootNode, 这可以是⼀个永久的根节点.
客户端获取锁, 现在lockRootNode下⾯创建⼀个顺序的瞬时节点, 保证客户端断开连接, 节点也⾃动删除.
调⽤lockRootNode⽗节点的getChildren()⽅法, 获取所有的根节点, 并从⼩到⼤排序, 如果创建的最⼩的节点是当前节点, 则返回true, 获取锁成功.
谈谈业务中使⽤分布式的场景.
⾸先, 需要连接系统为什么使⽤分布式.
随着互联⽹的发展, 传统的单体项⽬的性能瓶颈越发凸显, 性能瓶颈可能存在于⼀下⼏个⽅⾯:
应⽤服务层: 随着⽤户量的增加, 并发量增加, 单体项⽬难以承受如此之⼤的并发请求导致的性能瓶颈.
底层数据库层: 随着业务的发展, 数据库的压⼒也越来越⼤, 导致的性能瓶颈.
场景1: 应⽤系统集的Session共享.
应⽤系统集最简单的就是服务器集, ⽐如: Tomcat集. 应⽤系统集的时候, ⽐较凸显问题的就是Session共享, Session共享我们⼀是可以通过服务器插件去解决, 另⼀种也可以Processing math: 100%
通过Redis等中间件解决( ⼀般采⽤Redis中间件, 使⽤服务器插件复制的话 将Session实时同步到每⼀个服务器上, 这样只能⽀持Session数量⽐较少的情况, 使⽤Redis中间件存储的话, 性能⽐较⾼, ⽽且稳定性也更好. ).
场景2: 应⽤系统的服务拆分.
服务化拆分, 是⽬前⽐较⽕热的⼀种⽅式. 现在都在说微服务. 通过对传统项⽬进⾏服务化拆分, 达到服务独⽴解耦, 单服务⼜可以横向扩容. 服务化拆分遇到的经典问题就是分布式事务问题. ⽬前, ⽐较常⽤的分布式事务解决⽅案有⼏种: 消息最终⼀致性, TCC补偿性事务等.
场景3: 底层数据库的压⼒分摊
如果系统的性能压⼒出现在数据库我们就可以采⽤读写分离, 分库分表等⽅案进⾏解决.
分布式和微服务的关系
Session分布式⽅案
这⾥只介绍常⽤的两种.
2.1 基于Cookie的Session共享
将⽤户的session加密序列化之后, 以Cookie的⽅式保存在⽹站的根域名之下, 当⽤户访问所有⼆级域名的时候, 留恋其会传递所有匹配的根域名的Cookie信息, 这样实现了⽤户Cookie化Session的多服务共享. 此⽅案能够节省⼤量的服务器资源, 缺点是存储的信息长度将会受到http协议限制, ⽽且⼀个站点只能保存⼤约20条Cookie, ⽽且每次请求的时候都会带上session, 这样的话会造成⼀定的⽹络带宽浪费.
2.2 基于Redis的Session共享存储
这些键值对⾮关系型数据库有较⾼的性能, 可以轻松打到2000qps, 内置的过期机制正好满⾜Session的时效性特征.
在单独的服务器或者是服务器集上使⽤缓存技术, 使⽤Redis存储Session数据, ⼏种管理所有的Session, Redis可以做⾼可⽤集, 所有的Web服务器都从这个存储介质中读取相应的Session, 实现Session共享.
优点: 可靠性⾼, 在遇到性能瓶颈的时候可以横向扩展.
缺点: 实现略微复杂.
适⽤场景: Web服务器⽐较多, 可⽤性要求很⾼的状态.
可⽤⽅案: 开源⽅案Spring Session, 也可以⾃⼰实现.
3. 分布式锁的场景和实现.
使⽤场景
⾸先, 我们看这样⼀个场景, 客户下单的时候, 我们调⽤库存中⼼进⾏减库存, 那么我们的⼀般操作就是;
update store set num=numwhereid={id}
这种通过设置库存⽅式的修改, 我们知道在并发量⽐较⾼的时候回存在数据库的丢失更新, 如果A,B两个事物, 查询出来的库存都是5, a下了三个单⼦吧库存改为2, b下了⼀个单⼦将库存改为4, 这个时候出现了a回覆盖b的更新. 最终结果出现错误, 剩余库存为2.
这个时候我们需要采取CAS乐观锁去解决这个问题.
这⾥的CAS不需要考虑ABA问题, 因为即使这个时候加了库存, 中间发⽣了变化, 但是对于最终结果是不会产⽣影响的.
update store set num = numwhereid={id} and num = ${query_num}
这个是只更新⼀个表, 如果牵扯到多个表呢, 我们希望和这个单⼦关联的所有的表同⼀时间只能被⼀个线程来处理更新, 多个线程按照不同的顺序去更新同⼀个单⼦关联的不同数据的时候, 出现死锁的概率⽐较⼤. 如果是分布式项⽬的话, 我们需要保证多线程多进程同时只能有⼀个进⾏的⼀个线程去处理, 这个时候我们就需要⽤到分布式锁. 分布式锁的实现⽅式有很多种, 我们今天分别通过,Zookeeper, Redis以及Tair的实现逻辑.
Zookeeper实现
获取锁
现有⼀个锁根节点, lockRootNode, 这可以是⼀个永久的根节点.
客户端获取锁, 现在lockRootNode下⾯创建⼀个顺序的瞬时节点, 保证客户端断开连接, 节点也⾃动删除.
调⽤lockRootNode⽗节点的getChildren()⽅法, 获取所有的根节点, 并从⼩到⼤排序, 如果创建的最⼩的节点是当前节点, 则返回true, 获取锁成功.
搜索⽂件
谈谈业务中使⽤分布式的场景.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。