暂时未有相关云产品技术能力~
简介: CSDN优秀作者、华为云专家 领域: Java框架、并发编程、分布式、微服务、Redis、HarmonyOS、中间件等技术
Hystrix Dashboard是一个通过收集actuator端点提供的Hystrix流数据,并将其图表化的客户端。如果需要通过图表化的界面查看被断路器保护的方法相关调用信息、或者实时监控这些被断路器保护的应用的健康情况,就可以使用Hystrix Dashboard。
在微服务中,服务与服务之间的调用经常出现两个不确定性因素: 1. 网络延迟 2. 服务异常
Hystrix Dashboard虽然好用,但是它有一个缺点:一个Hystrix Dashboard只能收集一个微服务的Hystrix流。也就是说对于每个微服务,我们都需要开启一个Hystrix Dashboard来监控其健康情况。可以看到如下Hystrix Dashboard只能输入一个actuator端点地址。
Spring Cloud Config分为Server端和Client端。其中Spring Cloud Config Server是Spring Cloud为指定应用中所有服务提供集中式配置的一个服务,借助Spring Cloud Config Server可以实现集中管理所有应用的配置,避免重复配置。
Feign是一个REST客户端库,它通过接口驱动的方式来定义REST客户端。Spring Cloud Netflix体系中的Eureka服务注册中心客户端支持Ribbon客户端负载均衡器,而Feign本质上是Ribbon的包装,其内部是通过Ribbon来进行服务查找和负载均衡。
Eureka分区集群部署
Eureka非分区集群部署
Eureka入门
滑动窗口限流
漏斗限流
令牌桶算法比较简单,它就好比摇号买房,拿到号的人才有资格买,没拿到号的就只能等下次了(还好小编不需摇号,因为买不起!)。
Skip List(跳跃列表)这种随机的数据结构,可以看做是一个二叉树的变种,它在性能上与红黑树、AVL树很相近;但是Skip List(跳跃列表)的实现相比前两者要简单很多,目前Redis的zset实现采用了Skip List(跳跃列表)(其它还有LevelDB等也使用了跳跃列表)。
布隆过滤器(Bloom Filter)是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多,缺点是有一定的误识别率和删除困难。
Redis的非常快,很大一部分原因是因为Redis的数据存储在内存中,既然在内存中,那么当服务器宕机或者断电的时候,数据就会全部丢失了,所以Redis提供了两种机制来保证Redis数据不会因为故障而全部丢失,这种机制称为Redis的持久化机制。
Redis类似大多数成熟的数据库系统一样,提供了事务机制。Redis的事务机制非常简单,它没有严格的事务模型,无法像关系型数据库一样保证操作的原子性。
Bitmaps 称为位图,它不是一种数据类型。网上很多视频教程把Bitmaps称为数据类型,应该是不正确的。
HyperLogLog是用来做基数统计的算法,它提供不精确的去重计数方案(这个不精确并不是非常不精确),标准误差是0.81%,对于UV这种统计来说这样的误差范围是被允许的。HyperLogLog的优点在于,输入元素的数量或者体积非常大时,基数计算的存储空间是固定的。在Redis中,每个HyperLogLog键只需要花费12KB内存,就可以计算接近2^64个不同的基数。
Geospatial是Redis在3.2版本以后增加的地理位置GEO模块,这个模块可以用来实现微信附近的人,在线点餐“附近的餐馆”等位置功能。
CAP定理是分布式存储系统的基石,分布式系统(distributed system)指的是建立在网络上的软件系统,它是多个计算机节点通过协调工作的方式,共同完成任务的系统。分布式系统解决了单个计算机无法完成的计算和存储任务。但是分布式系统的设计十分复杂,设计者必定面临诸多挑战,比如节点故障、网络分区、异地网络等等问题。
CentOS安装Redis单实例
Redis一主二从Sentinel监控配置
CentOS 7单机安装Redis Cluster(3主3从伪集群)
Redis安装布隆(Bloom Filter)过滤器
如果遇到大量的批处理,我们可以考虑使用Redis的pipeline(管道)
Redis的Pub/Sub发布订阅,是Redis一步步完善消息队列功能的一个进步点,虽然现在没人用Pub/Sub做消息队列,但是它的思想和功能也是值得玩一下的,这个就是我写这篇文章的主要原因。
Stream弥补了Redis作为MQ(message queue)技术选型上的不足之处;Redis 5.0发布的Stream相比Pub/Sub模块,Stream支持消息持久化,结合sentinel或cluster使其成为了一个比较可靠的消息队列。尽管我认为它很难成为公司MQ的技术选型产品,但是关于Stream的使用和特性(消费组),仍值得一探究竟。
Redis的数据结构均可以通过EXPIRE key seconds 的方式设置key的过期时间(TTL)。我们也习惯的认为Redis的key过期时间到了,就会自动删除,显然这种想法并不正确。Redis的设计考虑到性能/内存等综合因素,设计了一套过期策略。
Redis是基于内存存储的key-value数据库,我们知道内存虽然快但空间小,当物理内存达到上限时,系统就会跑的很慢,这是因为swap机制会将部分内存的数据转移到swap分区中,通过与swap的交换保证系统继续运行;但是swap属于硬盘存储,速度远远比不上内存,尤其是对于Redis这种QPS非常高的服务,发生这种情况是无法接收的。(注意如果swap分区内存也满了,系统就会发生错误!)
LRU有一个明显的缺点,它无法正确的表示一个Key的热度,如果一个key从未被访问过,仅仅发生内存淘汰的前一会儿被用户访问了一下,在LRU算法中这会被认为是一个热key。
单一职责原则(Single Responsibility Principle,简称SRP),指的是不要存在一个以上导致类变更的原因。 There should never be more than one reason for a class to change.
工厂设计模式,可能是我们开发过程中无形之中使用的最多的设计模式。工厂设计模式包括简单工厂(Simple Factory)、方法工厂(Method Factory)、抽象工厂(Abstract Factory),其中简单工厂设计模式并包含在GOF23种设计模式之中,但是其使用也十分广泛;这三种设计模式之间存在一定的关系,层层递进;但是三种工厂设计模式各自有各自适用的场景,在实际开发中选择设计模式应该深思熟虑。
单例模式(Singleton Pattern),确保一个类只有一个实例,并提供对它的全局访问点。
Redis集群是Redis提供的分布式数据库方案,集群通过分片(sharding)进行数据共享。
主从复制奠定了Redis分布式的基础,但是普通的主从复制并不能达到高可用的状态。在普通的主从复制模式下,如果主服务器宕机,就只能通过运维人员手动切换主服务器,很显然这种方案并不可取。 针对上述情况,Redis官方推出了可抵抗节点故障的高可用方案——Redis Sentinel(哨兵)。Redis Sentinel(哨兵):由一个或多个Sentinel实例组成的Sentinel系统,它可以监视任意多个主从服务器,当监视的主服务器宕机时,自动下线主服务器,并且择优选取从服务器升级为新的主服务器。
主从复制是Redis分布式的基石,也是Redis高可用的保障。在Redis中,被复制的服务器称为主服务器(Master),对主服务器进行复制的服务器称为从服务器(Slave)。