一、2019-09-19 :
(1) hashMap :
1 由数组和链表构成,数组的优势查数据快,但是存数据慢,而链表的优势在于存数据快,取数据慢,所以当两个互补优势之后,存数据和查数据都会非常快。
2 默认的数组长度为16,当数据量达到0.75时,会进行动态扩容,扩容后的长度是2的N次幂,当达到1073741824时,就到了扩容的最大值,如果小于0.75会浪费空闲内存,如果大于0.75,多个值会存在一个链表中,从而产生哈希碰撞。
3 当数据进来后,会存在数组的哪一个位置,该位置是通过数组长度-1 然后与哈希code进行位与运算后算出来的结果,比如数组默认长度为16,存入的数据key的哈希值为3373707,那么对于这个数据进行位于运算,就是把16-1=15转化为2进制1111,而3373707转化为2进制最后四位是1011,然后两个数比较,如果都为1,那么就是1,有一个不为1就是0,
1111和1011,第一个数都为1 ,所以1,第二个有一个为0,所以为0,同理最后的出1011,转化为十进制为11,所以就会把这个key的数据存入到数组的11里面,
4 当数组中的链表长度到8时,链表会自动转化为红黑树
5 get数据流程:首先会把数据的key取出来,计算出哈希值,找到数组中对应的链表或者红黑树所在,用对应的方法取出数据。
(2) 分布式Spring Cloud的核心组件:
1.Eureka (注册调用中心)
Eureka是微服务架构中的注册中心,专门负责服务的注册与发现。Eureka分两部分,一个是client一个是server,client负责将这个服务的信息注册到Eureka Server中,Eureka Server是一个注册中心,里面有一个注册表,保存了各服务所在的机器和端口号,因为分布式有很多不同的系统,比如一个付款功能,有付款,发货,积分等等,这些服务都会有各自的client,client会把各自的服务注册到server,别的服务想要调用的时候,可以通过自己的client去server查找自己想要调用的服务
2.Feign(动态代理实现互相调用更加方便)
核心是spring的动态代理机制,直接就是用注解定义一个 FeignClient接口,然后调用那个接口就可以了,将底层的连接,请求,响应,等等全部包装好。实现原理就是如果对某个接口用了@FeignClient注解,他就会对这个接口实现一个动态代理。当其他地方调用这个接口时,调用的就是他的动态代理,然后Feign会根据RequestMapping请求方式,构建请求的地址,最后对这个地址发起请求。
3.Ribbon(轮询)
当同一个服务比如订单,分别部署到多台服务器上时,一个请求发过来,Ribbon会帮你在每次请求时选择一台机器,均匀的把请求分发到各个机器上,轮询算法,就是一台一台的循环。首先回去client中获取注册中心的信息,然后使用轮询找到应该给哪一个服务发送请求,Feign就会针对这台机器,构造并发起请求。
4.Hystrix(熔断器)
当付款请求发送后,既要实现积分,又要实现发货,如果当其中发货服务器炸掉了,那么,付款就会卡住,相应的其他都要炸,为了避免这种情况,这是就使用了Hystrix,Hystrix会搞很多个小小的线程池,每一个服务都对应一个线程池,如果一个服务挂了,他对应的线程池会挂,但是其他线程池不受影响,所以会继续工作,但是由于挂了一个服务,因为你依然去请求发货,所以及时其他服务不受影响,但是你依然会卡顿几秒钟,所以对他进行熔断,有问题的服务,进行溶断后最好对他进行一些处理,这种处理就是降级。
5.Zuul(网关)
所有请求都往网关走,网关会根据请求中的一些特征,将请求转发给后端的各个服务,因为所有的服务都要先从网管走,所以网管也能做一些降级、限流、权限、安全等处理。
6.总结
Eureka:各个服务启动时,Eureka Client都会将服务注册到Eureka Server,并且Eureka Client还可以反过来从Eureka Server拉取注册表,从而知道其他服务在哪里
Ribbon:服务间发起请求的时候,基于Ribbon做负载均衡,从一个服务的多台机器中选择一台
Feign:基于Feign的动态代理机制,根据注解和选择的机器,拼接请求URL地址,发起请求
Hystrix:发起请求是通过Hystrix的线程池来走的,不同的服务走不同的线程池,实现了不同服务调用的隔离,避免了服务雪崩的问题
Zuul:如果前端、移动端要调用后端系统,统一从Zuul网关进入,由Zuul网关转发请求给对应的服务
二、2019-09-20 :
(1)Consul服务注册中心
Consul由两部分组成,分别是每一个服务所在服务器都有一个Consul Agent,agent会把服务注册到Consul Server中,互相之间访问其实是去server中找到其他的agent注册的信息,进行问, consul的server会部署到几台服务器上,会从这几个机子上选择一个Leader,每一个agent去访问都是leader,其他的是follower,当leader挂了,会去其他follower通过选举机制重新选举出一个leader,他们之间会自动实现数据同步,以保证高可用以及数据一致性。
Consul与Eurake的比较
1.首先Consul 与 Eurake都由两部分组成,consul由agent与server ,eurake由client与server组成,agent与client都是负责把各自的服务注册到server上的。
2. 检查服务是否可以用,Eurake使用的是心跳机制,client会定时的传给server一个心跳,告诉server是否自己宕机,如果一定时间内server没有接收到某个server发送过来的心跳,则会判断它宕机了,这样的机制会导致一个问题,就是server日常接收到的信息百分之八十都是发送过来的心跳信息,当有几千个服务一直发的时候,会大大的影响性能,就是因为心跳机制,所以Consul引入了Agent概念,每个机器上的Consul Agent会不断的发送请求检查服务是否健康,是否宕机。如果服务宕机了,那么就会通知Consul Server。这就是Consul基于Agent实现的分布式健康检查机制,可以大幅度的减小Server端的压力。
(2)分布式系统容错架构
简单的说就是同一个数据库的相同数据,分别放在好多台服务器上,如何保证数据库中的数据不出现问题。
1.分布式存储系统的两种进程。
一个进程是Master节点,就在一台机器上,负责统一管控分散在多台机器上的数据(读取数据会去这里读取,然后由它去其他服务器上找数据)。另外一批进程叫做Slave节点,每台机器上都有一个Slave节点,负责管理那台机器上的数据,跟Master节点进行通信。
2多副本冗余的架构。
简单的说就是在其他服务器备份自己数据库。比如一个数据库t_order里面有一亿条数据,分别存在5台服务器上,每一台服务器的数据库里面都有2千万条数据,如果一台机子宕机了,而现在又有一个查询过来查找数据,那他就只能查到8千万条数据中自己想要的,这肯定不行,而多副本冗余就是为此而生,每一个服务器上的数据库都会在其他多个服务器上备份自己的数据,如果有一个机子宕机了,但是其他服务器上依然有它的备份,所以查询的数据不会丢失。Master节点如何感知到数据副本消失?依然是通过心跳,每一个slave节点都会往master上发送心跳,如果一段时间没有发送,而正好又有服务需要查找对应的数据,master会安排这个服务器其他没有宕掉的服务器上找。每有一个服务器宕机,master会在其他有机子发送心跳的时候在其中找一个服务器为它备份数据,这样就可以保证备份的数量不会变少,出现数据库丢失的情况。而如果宕机的服务器又重新启动了,这样备份就会多一份,而master一旦受到宕机的服务重新启动,会发送一个删除指令,将宕机服务器本地的数据库副本删除 ,以保证副本的数据不变。
(3)分布式搜索引擎的架构原理(Elasticsearch为列。简称es)
1.倒排索引
比如如下的数据存在数据库中
id title content
1 Java好用吗? Java是非常非常好的一门语言。。。。
2 大家一起来学Java 我这儿有一些很好的Java学习资源,比如说。。。
3 一次Java面试经验 去年这个时候,我学了Java,今年开始了面试。。。
用数据库来进行搜索会 是 like %java%
而倒排索引是吧数据转化为
关键词 id
Java [1, 2, 3]
语言 [1]
面试 [3]
资源 [2]
所谓的倒排索引,就是把你的数据内容先分词,每句话分成一个一个的关键词,然后记录好每个关键词对应出现在了哪些id标识的数据里。那么你要搜索包含“Java”关键词的帖子,直接扫描这个倒排索引,在倒排索引里找到“Java”这个关键词对应的那些数据的id就好了。
2.分布式搜索引擎
把大量的索引数据拆散成多块,每台机器放一部分,然后利用多台机器对分散之后的数据进行搜索,所有操作全部是分布在多台机器上进行,形成了完整的分布式的架构。
3.Elasticsearch的基础名词
index:相当于数据库存的数据的索引,里面有很多数据。
document:index中的一条数据,这个document可以写到index里去,算是index里的一条数据,写到es之后,这条数据的内容就会拆分为倒排索引的数据格式来存储。
4.Shard数据分片机制
每一个index都有很多的Shard,Elasticsearch默认五个,用来分别储存index中的数据,shard直接可以分布式的并行对一部分数据进行搜索,起到一个分布式搜索的效果,大幅度提升海量数据的搜索性能和吞吐量。
5.Replica多副本数据冗余机制
每个shard会自己复制一份对应的replica副本到其他服务器,这样即使本机宕掉搜索也不会受到影响,Elasticsearch默认每个primary shard有1个replica shard作为副本。