上某个微服务的调用响应时间过长或者不可用,那么微服务调用者就会阻塞线程,占用越来
越多的系统资源,进而崩溃,同理影响调用者的调用者,一步步崩溃,就是所谓的"雪崩效应".
服务熔断机制就是:应对雪崩效应的一种微服务链路保护机制.扇出链路的某个微服务不可
用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回"错误"
的响应信息.当检测到该节点微服务调用响应正常后恢复链路.在 SpringCloud 框架里熔断
机制通过 Hystrix 实现.
Hystrix 会搞很多个小的线程池,比如我们订单服务请求库存服务是一个线程池,请求仓储
服务是一个线程池,请求积分服务是一个线程池.每个线程池里的线程就仅用于请求那个服
务,当某个线程池线程到达阈值时就启动服务熔断,服务降级,如果其他请求继续访问就直接
返回 fallback 的默认值.
(问题:redis 为什么块?单线程不应该慢吗?)
Redis 是一个非常优秀的,高性能的 NoSQL 数据库,他之所以效率高,我认为主要是他纯内存
数据库,在内存中存取数据相当快,它存储的是 key-value 结构,这种哈希方式查找速度非常
快,Redis 虽然是单线程,但他采用了 Linux 系统的 epoll 技术,实现网络 IO 多路复用技术,
保证在多连接时系统的高吞吐量,提高了性能.Epoll 是目前最高效能降低在高并发少活跃
情况下 Cpu 的占用率方法,Epoll 最大的好处在于它不会随着监听文件句柄数目的增长而降
低效率,无须遍历整个被监听的描述符集,只要遍历那些被 IO 事件异步唤醒而加入 Redis 队
列的描述符集合就行了,正因为 Redis 是单线程的,它避免了不必要的上下文切换和竞争条
件,也不存在多进程或者多线程导致的切换消耗 CPU,不用去考虑各种锁的问题,不存在加锁
释放锁操作,没有因为可能出现死锁而导致的性能消耗.
(问题:Redis 持久化机制)
第一种是 RDB 快照模式,也是默认方式,它会把内存中所有的数据都保存到磁盘上.它会在三
种情况下保存,一是根据配置触发,二是客户端手动执行 save 命令,三是服务器正常退出时
也全部保存.RDB 缺点很明显,容易丢失数据,写入到数据大,不适合小内存机器.
第二种是 AOF 追加模式,它只记录最后执行了更新命令的数据.优点是丢失的数据少,最大丢
失一秒的数据,写入压力小,它追加最后一条.缺点是文件会越来越大,数据恢复也会越来越
慢,AOF 需要手动打开 Redis4.0 之后 AOF 和 RDB 可以结合使用
(问题:为什么 MongoDB 适合大数据的存储)
其实不只是非关系型数据库,关系型数据库同样可以存放大量数据,只不过数据达到某个量
时查询效率下降,那么针对于 MongoDB 数据是暂时存放到内存中,然后就是 MongoDB 使用的
是 javascript 语法,还有就是对于 MongoDB 是没有像咱们 Mysql 这种表关系存在的,那也就
是相当于每个数据都有一个单独的存储空间,通过一个索引指向下一个,所以搜索性能相对
来说会高一些
(问题:es 近实时)
