分布式学习相关

一.分布式锁

1.底层实现,使用setnx key value命令

	将key的值设为value,当且仅当key不存在时
	如果key已经存在不做任何操作

2.具体实现分布式锁

在这里插入图片描述

3.分布式锁的性能优化(高并发场景下)

	分段锁提高高并发时的性能
	例如ConcurewnthashMAP

4.缓冲数据库数据一致性解决方案

	1)延时双删策略
	延时部分时间,再次删除缓存;影响性能,并且延时时间不容易确定;
	2)内存队列
	将读操作放入同一个队列中,依次执行
	3)分布式锁
	使每一个线程操作是原子性,排队执行,性能降低;
	优化:读写锁
	4)例如ConcurewnthashMAP

二.CAP理论,BASE理论

1.CAP理论

a)Consistency(一致性)

更新操作成功后返回客户端后,所有节点在同一时间的数据完全一致。对于客户端来说,一致性指的是并发访问时更新的数据如何获取的问题。从服务端来看,是更新如何复制分布到整个系统,以保证数据的一致性。

b)Avaliability(可用性)

服务一直可用,而且是正常响应时间。系统能够很好地为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。

c)Partition Tolerance(分区容错性)

分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统,但看上去却 好像是一个可以运转正常的整体。比如现在的分布式系统中有一个或几个机器宕机了,其他剩余的机器还能够正常运转满足系统的需求,对于用户而言并没有什么体验山的影响。
CP和AP:分区容错是必须保证的,当发生网络分区的时候,如果要继续服务,那么强一致性和可用性只能2选1。

2.CAP理论

BASE理论是对CAP重一致性和可用性权衡的结果,其来源与对大规模互联网系统分布式实践的总结,是基于CAP定理逐步演化而来的。BASE理论的核心思想是:即使没办法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。

a)基本可用

a) 相应时间上的损失:正常情况下,处理用户的请求可能需要0.5s返回结果,但是由于系统出现故障,处理用户的请求时间变为了3s.
b) 系统功能上的损失:正常情况下,用户可以使用系统的全部功能,但是由于系统的访问量突然剧增,系统的部分非核心功能无法使用。

b)软状态

数据同步允许一定的延迟

c)最终一致性

系统中所有的数据副本,在经过一段时间的同步后,最终能够到达一个一致 的状态,不要求是实时。

三.负载均衡算法,类型

1.负载均衡算法

a)轮询法

将请求按顺序轮流地分配到后端服务器上,它均衡地对待后端的每十台服务器,而不关心服务器实际的连接数和当前的系统负载。

b)随机法

通过系统的随机算法,根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知,随着客户端调用服务端的次数增多,其实际效果越来越接近于平均分配调用量到后端的每一台服务器,也就是轮询的结果。

c)源地址哈希法

源地址哈希的思想是根据获取客户端的IP地址,通过哈希函数计算得到的一个数值,用该数值对服务器列表的大小进行取模运算,得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡,同一IP地址的客户端,当后端服务器列表不变时,它每次都会映射到同一台后端服务器进行访问。

d)加权轮询法

不同的后端服务器可能机器的配置和当前系统的负载并不相同,因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重,让其处理更多的请;而配置低、负载高的机器,给其分配较低的权重,降低其系统负载,加权轮询能很好地处理这一问题,并将请求顺序且按照权重分配到后端。

e)加权随机法

与加权轮询法一样,加权随机法也根据后端机器的配置,系统的负载分配不同的权重。不同的是,它是按照权重随机请求后端服务器,而非顺序。

f)最小连接数法

最小连接数算法比较灵活和智能,由于后端服务器的配置不尽相同,对于请求的处理有快有慢,它是根据后端服务器当前的连接情况,动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求,尽可能地提高后端服务的利用效率,将负责合理地分流到每一台服务器。

2.负载均衡类型

a)DNS方式实现负载均衡

b)Zp2硬件负载均衡:E5和A10软件负载均衡

c)软件负载均衡:

Nginx、HAproxy、LVS。其中的区别:
Nginx:
七层负载均衡,支持HTTP、E-mail协议,同时也支持4层负载均衡;作用于应用层的负载均衡,根据URL一定的规则进行路由选择不同的server层;跟客户端和服务端建立长连接,资源消耗比较多,性能偏低。
HAproxy:
支持七层规则的,性能也很不错。Openstack默认使用的负载均衡软件就是HAproxy;
LVS:
运行在内核态,性能是软件负载均衡中最高的,严格来说工作在三层,所以更通用一些,适用各种应用服务。在传输层做负载均衡,主要作用是转发,改掉server层目标ip

四.分布式架构下,Session共享有什么方案?

1、采用无状态服务,抛弃session
2、存入cookie(有安全风险)
3、服务器之间进行Session同步,这样可以保证每个服务器上都有全部的Session信息,不过当服务器数量比较多的时候,同步建会有延迟甚至同步失败;
4、IP绑定策略
使用Nginx(或其他复杂均衡软硬件)中的IP绑定策略,同一个IP只能在指定的同一个机器访问,但是这样做失去了负载均衡的意义,当挂掉一台服务器的时候,会影响一批用户的使用,风险很大;
5、使用Redis 存储
把Session放到Redis中存储,虽然架构上变得复杂,并且需要多访问一次Redis,但是这种方案带来的好处也是很大的:
实现了Session 共享;
可以水平扩展(增加Redis服务器);
服务器重启 Session不丢失(不过也要注意Session在Redis中的刷新/失效机制);
不仅可以跨服务器Session共享,甚至可以跨平台(例如网页端和APP端)。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值