- 博客(83)
- 收藏
- 关注
RSS订阅原创 Sentinel源码分析-ProceesorSlotChain调用链及树状资源节点
ClusterBuilderSlot 则用于存储资源的统计信息以及调用者信息，例如该资源的 RT, QPS, thread count 等等，这些信息将用作为多维度限流，降级的依据；ProcessorSlotChian 实现上述功能的骨架，这个类是基于责任链模式设计，将不同功能（限流，降级，系统保护）封装为一个个的Slot，请求进入后逐个执行。NodeSelectorSlot 负责收集资源的路径，并将这些资源的调用路径，以树状结构存储起来，用于根据调用路径来限流降级；责任链中Solt 也分为两大类。
2023-06-14 19:36:13
1341
原创 Sentinel的限流和Gateway的限流差别？
并发的多个请求必须等待，预期的等待时长-最近一次请求的预期等待时间+允许的间隔。比如是1250ms 时来个请求，1250-1000=250， 250后面的第一个时区是500-100。限流算法常见的有三种实现：滑动时间窗口，令牌桶算法，漏桶算法。例如： QPS=5 ，意味这没200ms处理一个队列中的请求，timeout=2000,意味着预期等待超过2000ms的请求会被拒绝并抛出异常。观上图，这种算法使用问题的，在4500-5500ms 这1s内有6个请求通过。漏桶算法是对令牌桶算法的改进。
2023-06-14 18:28:58
2423
原创 Sentinel与Hystix的线程隔离有什么差别
Hystix 默认是基于线程池实现线程隔离，每个被隔离的业务都要创建一个独立的线程池，线程过多会带来额外的CPU开销，性能一般，但是隔离性更强。Sentinel 是基于信号量（计算器）实现的线程隔离，不用线程池，性能较好，但是隔离性一般。Sentinel与Hystix的线程隔离有什么差别？
2023-06-14 16:36:02
1464
原创 springcloud-Nacos临时实例永久实例
对于集群下的服务，Nacos ⼀个服务只会被 Nacos 集群中的⼀个注册中心所负责，其余节点的服务信息只是集群副本，用于订阅者在查询服务列表时，始终可以获取到全部的服务列表。临时实例只会对其被负责的注册中心节点发送心跳信息，注册中心服务节点会对其负责的永久实例进行健康探测，在获取到健康状态后由当前负责的注册中心节点将健康信息同步到集群中的其他的注册中心。临时实例会与注册中心保持心跳，注册中心在一段时间没有收到实例的心跳后，将实例设置为不健康，然后再一段时间后剔除。临时实例和永久实例的区别。
2023-06-14 16:03:06
444
原创 springcloud-Nacos处理高并发的注册
添加服务第一 次判断 提供性能：避免多个线程同时在等 synchronzied 释放第二次 判断 ： 别的线程可能已经将实例加入了 serviceMap()注意这里还有个ConcurrentSkipListMap 有利于提高读写性能。所以内层的Map 是个ConcurrentSkipLlistMap，添加实例。
2023-06-14 13:48:22
1022
原创 springcloud-Nacos-注册表结构
然后是group，用来对服务的分组，接下来就是服务（Service）了，一个服务包含多个实例，但是可能处于不同的机房，因此Service下有多个集群（cluster）.cluster 下面不同的实例。内存Map的Map的key 是groupName+ServiceName,值是Service 对象。Service 对象内部又是一个Map, key是集群名称，值是Cluster对象。问题说明：考察对Nacos数据分级结构的了解，以及Nacos源码的掌握情况。
2023-06-14 11:36:01
137
原创 Rabbitmq-集群
镜像集群虽然支持主从，但主从同步并不是强一致性的，某些情况下可能有数据丢失的风险。因此在RabbitMq的3.8版本以后退出了新的功能：仲裁队列来替代镜像集群。底层采用Raft协议确保主从的数据一致性。RabbitMq是天然支持集群模式。是用来替换镜像队列的。
2023-06-13 19:29:34
1940
原创 RabbitMq消息堆积问题及惰性队列
普通的队列会设置一个预警值默认40% 当队列到了40%时，mqBroker 会阻止生产者发送消息。而惰性队列呢在接收消息后会直接写到磁盘，所以不会触发队列的存储预警，性能具有稳定性，延迟性。当生产者发送消息的速度超过了消费者处理的速度，就会导致队列的消息堆积，知道队列存储消息达到上限。最早接受的消息，可能就会成为死信，会被丢弃，这就是消息堆积问题。rabbitmq3.6.0 版本开始，新增了Lazy Queues概念，也就是惰性队列。正因为惰性队列支持百万的消息存储，所以用它来解决消息堆积问题再好不过了。
2023-06-13 17:50:10
1683
原创 RabbitMq死信交换机
如果该队列设置了 dead-letter-exchange属性，指定了一个交换机，那么队列中的私信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchagne,简称DLX）给队列设置dead-letter-routing-key属性，设置死信交换机与死信队列的routingkey。利用TTL结合死信交换机，我们实现了消息发出后，消费者延迟收到消息的效果。因为延迟队列的需求非常多，所以Rabbitmq 的官方也推出了一个插件，原生支持延迟队列的效果。通过下图 我们可以明白了，
2023-06-13 16:06:46
2569
原创 ElasticSeach-自定义分词器
character filters : 在tokenizer 之前对文本进行处理，例如删除字符替换字符tokenizer: 将文本按照一定的规则切割成词条（term）。例如keyword就是不分词，还有ik_smarktokenizer-filters: 将tokenizer 输出的词条进一步处理。例如大小写转换，统一次处理，拼音处理等。创建索引时，使用拼音分词器查询文档时，不使用拼音分词器，用ik_max_smart或 ik_smart。
2023-06-09 16:28:58
271
原创 SpringCloud-Gateway过滤器
请求进入网关会碰到三类过滤器： 当前路由的过滤器，DefaultFilter,GlobalFilter.请求路由后，会将当前路由过滤器和DefaultFilter,GlobalFilter，合并到一个过滤器连中。排序后后一次执行。这 也是全局过滤器 上要加@Order 或实现getOrder()方法的原因。
2023-06-07 17:32:28
784
原创 Spring 三级缓存
A 注入到C，A注入到B,又需要从第三级缓存中获取实例，而第三级缓存里保存的并非真正的实例对象，而是ObjectFactory对象。不提前创建好代理对象，在出现循环依赖被其他对象注入时，才实时生成代理对象。其实A对象的实例已经被添加到第二级缓存中了，而在A注入到C时，只用从第二级缓存中获取该对象即可。不管有没有循环依赖，都提前创建好代理对象，并将代理对象放入缓存，出现循环依赖时，其他对象直接就可以取到代理对象并注入。如果创建的Bean有对应的代理，那其他对象注入时，注入的应该是对应的代理对象；
2023-06-07 15:39:56
940
原创 kafka-broker-文件存储机制
Topic 是逻辑上的概念，而partition是物理上的概念， 每个 partition 对应一个log文件，该log文件中存储的就是producer生产的数据。Producer生产的数据会被不断追加到该log文件夹的末端，为了防止log文件过大而导致数据查询效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment.每个segment包括： “.index”文件和 “.log”文件及.timeindex 等文件。
2023-06-02 17:02:34
102
原创 kafka-broker-LeaderPartiion负载均衡
正常情况下，kafka 本身会自动把Leader Parition 均匀分布在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某些borker 宕机了，会导致Leader Partition 过于集中在其他少部分几台broker上，这会导致少数borker的读写请求压力过高，其他宕机的Borker 重启之后都是Follwer Partition，读写请求底，造成集群负载不均衡。建议不要开启，自动 leaader partition平衡需要 耗费大量的时间。
2023-06-02 13:52:18
128
原创 kafka-生产者-数据可靠性
由于acks=-1，生产者发送过来的数据，需要Leader 和ISR队列里面的所有节点收到数据后完成应答。但是如果 数据完成同步时，还没有应答的情况下，机器挂了。生产者没有收到应答信息，又回重新发送一次数据。因此 leader收到了两份数据。
2023-06-01 17:53:15
47
原创 kafka-生产者-提高生产者吞吐量-参数配置
batch.size: 默认16k， 只有数据积累到batch.size之后，sender才会发送数据。linger.ms: 等待时间，单位ms, 默认是0ms。修改为5-100ms,会导致数据延迟。compression.type: snappy 压缩recordAccumulator: 缓存区大小，默认32m，修改为64m。
2023-06-01 17:18:10
372
原创 kafka-生产者-自定义分区器
研发人员可以根据企业需求，自己重新实现分区器（1）需求假如我们实现一个分区器，发送过来的数据中包含某个beijing，就发发往0号分区，不包含beijing 就发往 1号分区@Override} else {> map) {} }/*** kafka生产者-自定义分区// 配置 Properties properties = new Properties();
2023-06-01 16:35:43
146
原创 kafka-生产者-分区
（1）便于合理使用存储资源，每个partition在一个Broker上存储，可以把海量的数据按照分区切割一块一块数据存储在多台broker上。合理控制分区的任务，可以实现负载均衡的效果。（2）提高并行度，生产者可以分区为单位发送数据；消费者可以以分区单位进行消费数据。partition= order.hashcode()/partition的数量.非常简单，只需要将表名作为key即可。比如 order表。如果将订单的数据发送一个指定的分区？
2023-06-01 16:15:35
69
原创 kafka-生产者-同步函数
只有当下图中的Qqueue 中的数据被成功发送到 kafka broker的partition中，生产者才会把外部的数据 send到 Dquue。
2023-06-01 15:30:51
35
原创 kafka基础架构
consumer: 消费者，向kafka broker去消息的客户端。product: 生产者，kafka broker 发消息的客户端。
2023-06-01 14:20:48
28
原创 redis7 hash之listpack
在获取 element内容的时候，先去读取当前element的len属性，不用ziplist那样去计算。读取完根据下一个element的len属性来读取内容。先回顾下 zilist。
2023-05-31 19:49:04
106
原创 Redis6 数据结构Hash
在Redis中，hashtable 被称为字典（dictionary）,它是一个数组+链表到结构。每个键值对都会有一个dictEntry这种编码夯实内部才是真正的哈希表结构，或称为字典结构，其可以实现O(1)复杂度的读写操作，因此效率很高。在Redis内部。
2023-05-31 18:55:16
572
原创 redis 数据结构String之SDS
当字符串的键值为长度大于44的超长字符串时，redis则会将键值的内部编码改为OBJ_ENCODING_RAW，这与OBJ_ENCODING_EMBSTR编码方式的不同之处在于，此时动态字符串sds的内存与其依赖的redisObject的内存不在连续了。字符串保存的小于44字节的字符串值，则使用简单动态字符串（SDS）结构，并将编码设置为raw，此时内存结构与SDS结构一致，内存分配次数为两次，创建redisObject对象和sdshdr结构。如：访问当前字符串的长度，直接读取即可，时间复杂度0(1)。
2023-05-31 17:00:13
584
原创 redis高级篇 缓存双写一致性之更新策略
是指在第一次删除之后，延迟一段时间再次进行删除，所以我们把它叫做“延迟双栓”。删除成功则已出，删除失败重试。如果重试次数较多，加入死信队列，后续处理，排查故障。这个方案在第一次删除之后，延迟一段时间再次进行删除，所以我们把它叫做“延迟双栓”2.如果redis 中无数据： 数据库中的值如果是最新的，则要写入到redis。因为要删除2次，所以吞吐量会降低，另起一个线程，异步删除。如果redis 删除成功， 数据库删除失败，则数据不一致。缓存中使错误的数据，数据不一致，且高并发下问题更是严重。
2023-05-26 19:01:17
813
原创 Redis BigKey问题
非字符串的bigkey，不要使用del删除，使用hscan，sscan,zscan的方式渐进式删除，同时防止bigkey过期自动删除问题，例如一个200w元素的list设置一个小时过期，会触发del操作。与del命令不同的是，unlink命令会异步地删除指定的键以及与之相关联的值。即，它会将要删除的键添加到一个待删除的列表中，并立即返回，不会阻塞客户端。在这么长 时间内，所有其他读写命令都会延后甚至报错，随着命令的积压，可能会造成缓存雪崩，甚至数据库宕机。
2023-05-26 14:25:52
878
原创 Redis6/7多线程总结
redis将所有数据放到内存中，内存的响应速度大概是100纳秒，对于小数据包，redis服务器可以处理8w到10w的QPS,这也就是Redis的处理极限了。如果你在实际的开发中，发现redis实例的CPU开销不大但是吞吐量没有提升，可以考虑使用Redis7多线程机制,加速网络I/O处理，进而提升吞吐量。这个数量使用讲究的，如果服务器是4核CPU，那么建议设置2-3个io-thread.如果是8核CPU，那么建议使用6个。在redis6/7中，多线程机制默认是关闭的。对于大数据的key的删除还是耗时的问题。
2023-05-25 15:37:07
325
原创 Redis 主线程和IO线程是如何完成协作处理的
从Redis6开始，就新增了多线程功能来提高I/O读写能力，它主要实现思路是：将主线程的读写任务拆分成一组独立的线程去执行，这样就可以使多个socket的读写并行化。采用I/O多路复用技术可以让单个线程高效处理多个连接请求（减少网络IO的时间的消耗），将最耗时的socket读取，请求解析，写入单独外包出去，I/O的读写本身是堵塞的，比如socket有数据时。而这个拷贝过程是阻塞的，当数据量越大，所需要的时间就越多。仍然由主线程执行，并将结果写入内存。网络IO操作就变成了多线程化，其他线程仍然是线程安全的。
2023-05-25 15:03:42
219
原创 redis高级篇一
主要是指redis的网路IO和键值对的读写是由一个线程来完成的，Redis在处理客户端的请求时，包括获取（socket 读），解析，执行，内容返回（socket 写）等，这些按顺序串行的命令由一个线程执行，这就是所谓的单线程。这也是redis对外提供键值存储的主要流程。比如redis-cli -a 11111 --raw 对应 创建socket 解析请求set k1 v1 对应 执行操作 返回的结果对应 写入socket。
2023-05-25 13:17:57
737
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人