- 博客(30)
- 收藏
- 关注
RSS订阅原创 内部类解析
整理了一下内部类的相关知识，算是比较全，比较基础的，希望大家一起学习进步。在Java中，可以将一个类的定义放在另外一个类的定义内部，这就是内部类。内部类本身就是类的一个属性，与其他属性 定义方式一致。} } }什么是回调？假设有两个类A和B，在A中调用B的一个方法b，而b在执行又调用了A的方法c，则c就称为回调函数。当然，回调函数也可以是a函数，这就是同步回调，最简单的回调方式。回调应用场景挺多的，如android中的事件监听器。匿名内部类可以很方便的定义回调，看个例子。
2024-02-18 11:30:03
916
原创 RocketMq基础概念及原理
为了增强Broker 性能与吞吐量，Broker一般都是以集群的形式出现的，各集群节点中可能存放着相同的Topic的不同Queue不过，这里有个问题，如果某个Broker节点宕机，如何保证数据不丢失呢，其解决方案为，将每个Broker集群节点进行横向扩展，即将Broker节点再建为一个HA集群，解决单点问题。
2023-07-15 10:29:59
382
原创 记录一次windows 安装 RocketMQ以及RocketMQ_console的流程
10912：haListenPort, haListenPort参数是HAService服务组件使用，用于Broker的主从同步，默认为ListenPort - 1 可以通过配置文件修改。listenPort：listenPort参数是broker的监听端口号，是remotingServer服务组件使用，作为对Producer和Consumer提供服务的端口号，默认为。remotingServer可以处理客户端的所有请求，如：生产者发送消息的请求，消费者拉取消息的请求，10911，可以通过配置文件修改。
2023-06-15 10:29:01
774
1
原创 线上环境单体数据库过度分库分表
线上现在又一个单库单表的系统，在线上跑，假设表中有600万的数据，此时在本地已经部署好了三天服务器，并且通过数据读取系统将所有的数据已经迁移到本地数据库，需要将线上的单库系统切换到分库系统。
2023-06-12 10:24:07
91
原创 数据拆分之分库分表
综上所述，现目前可以去做考量的就是sharding-jdbc和mycat，这个都是可以考虑使用，sharding-jdbc这种client层方案的优点就是不用部署，运维陈本地，但是如果遇到升级啥的，就需要各个系统重新升级版本在发布mycat这种proxy层方案的优点在于需要部署，自己及运维一套中间件，运维成本高，但是好处在于多个各项目是透明的，如果遇到升级之类的，都是自己的中间件哪里去升级就可以。
2023-06-11 15:07:28
43
原创 分布式系统-分布式事务
其实在一个项目中，需要用到分布式事务相关的地方还是比较少，因为通过上面的几个方案来看，任何一个地方使用分布式事务，都会导致相关位置的代码复杂度提升十倍，同时会极大的降低系统的吞吐量以及性能所以在线上其实99%的分布式事务场景，尽量不要做分布式事务，一般来说会使用监控(当问题产生时，发送邮件，短信等)，记录好日志(一旦出错，记录好完整的日志)，事后快速的定位，排查和出解决方案，修复数据等。
2023-06-11 11:21:22
48
原创 分布式Session实现方案
这个其实是很方便的，就是使用Session的代码和以前一样，还是基于Tomcat原生的session支持即可，然后就是用一个叫Tomcat RedisSessionManager的东西，让所有部署的Tomcat都将Session数据存储到Redis中。搞一个类似上面的配置可，使用RedisSessionManager，然后指定Redis 的host 和 port就可以了。还可以用上面这种方式，基于redis哨兵支持的redis高可用集群来保存session数据。可以再Tomcat 配置文件中配置一下。
2023-06-09 09:37:27
85
原创 分布式系统----分布式锁
zk分布式锁，其实可以做的比较简单，就是某个节点尝试创建临时的znode,此时创建成功，就获取了这个锁，这个时候别的客户端来创建锁就会失败，只能注册个监听器监听这个锁，一旦释放锁就是删除掉这个znode，一但释放掉就会通知客户端，然后有一个等待着的客户端就可以重新加锁。另外一点就是，如果redis获取锁的那个客户端BUG或者挂了，那么只能等待超时时间之后才能释放锁，而如果ZK的话，因为创建的是临时的znode，只要客户端挂了，那么znode就没了，此时就自动释放锁。
2023-06-03 10:19:03
52
原创 zookeeper的使用场景
对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行，另外一台机器在执行，那么此时就可以使用zk分布式锁，一个机器接收到了请求之后，先获取zk上的一把分布式锁，就是可以去创建一个znode，接着执行操作，然后另外一个机器也尝试去创建那个znode，结果发现自己创建不了，因为已经存在了,那就只能等待，等第一个机器执行完了在进行执行。这个其实是zk很经典的一个用法，简单来说 A系统发送个请求到MQ，然后B系统消费之后处理了，那A系统如何直到B系统的处理结果？
2023-05-31 14:33:53
46
原创 分布式系统中的接口幂等性和顺序性
其实在一般的情况下，分布式系统中的顺序性不是必须要求的，但是再某些极端情况下，需要保证接口调用的顺序性，譬如说，需要对一条数据进行修改后删除，但是执行时顺序错了，先删除再修改，那么本来这条数据应该被删除，但是现在数据还存在，导致后续很多问题。这个问题在分布式系统中很常见，所谓的幂等性，就是说一个接口，多次发起同一个请求，你这个请求得保证结果是准确的，比如不能多扣款，不能多插入一条数据，不能将统计值多加了1，这就是幂等性。
2023-05-31 11:42:51
69
原创 Dubbo的服务治理，降级，重试
需要自动统计各个接口和服务之间的调用次数以及访问延时，而且要分成了两个级别，一个级别是接口力度，就是每个服务的每个接口每天被调用多少次，TP50，TP90,TP99三个档次。dubbo做的分布式系统中，对各个服务之间的调用自动记录下来，然后自动将各个服务之间的依赖关系和调用链路生成出来，做成一张图。一个大型的分布式系统，分布式系统是由大量的服务组成，调用链路实际上是多个服务之间的调用记录。服务分层(避免循环依赖)，调用链路失败监控和报警，服务鉴权，每个服务的可用性的监控。
2023-05-31 11:15:22
50
原创 Dubbo的负载均衡，高可用，动态代理
一致性hash算法，相同参数的请求一定分发到一个provider上去，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大，如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。还有roundrobin loadbalance，这个的话默认就是均匀得将流量达到各个机器上，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高，所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。失败自动切换，自动重试其他机器，默认就是这个，常见于读操作。
2023-05-31 10:20:21
122
原创 Dubbo支持的通讯协议以及序列化协议
Dubbo是基于不同的通讯协议，支持hessian,java二进制序列化，json,soap文本序列化多种序列化协议，但是hessian是其默认的序列化协议。Dubbo本身是支持不同的通讯协议的，主要有以下几种。
2023-05-31 09:33:10
334
原创 dubbo的工作原理
可以的，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地，所以注册中心挂了可以继续通信。cluster层，集群层，封装多个服务提供这的路由以及负载均衡，将多个实例组合成一个服务。层，服务代理层，透明生成客户端的stub和服务端的skeleton。monitor层，监控层，对RPC接口的调用次数和调用时间进行监控。exchange层，信息交换层， 封装请求响应模式，同步转异步。Service层，接口层， 给服务提供者和消费者来实现的。registry层，服务注册层，负责服务的注册与发现。
2023-05-28 11:10:16
47
原创 分布式系统介绍
分布式系统分为两种，一种是底层相关的分布式，涉及到底层的一些架构，存储，算法等，另一种是分布式业务系统，把原来用java开发的一大块系统，拆分成多个子系统。
2023-05-28 09:49:46
41
原创 Redis并发竞争问题
线上非常常见的一个问题，就是多客户端同时并发写入一个key,可能本来应该先到的数据后到了，导致数据版本错了，或者是多客户端同时获取一个key，修改值之后再写回去，只要顺序错了，数据就错了而且Redis自己就有天然解决这个问题的CAS类的乐观锁方案。
2023-05-23 10:49:18
253
原创 Redis相关缓存问题:雪崩，穿透
缓存雪崩其实有很多的原因，缓存服务器宕机，或者缓存服务器集群故障，等等，总体来说属于系统架构中的缓存部分架构失效，导致大量的请求到达持久层数据库，由数据库处理请求，但是数据库的每秒并发最高不能超过2000个，突然增大的流量访问可能会直接让数据库挂掉，此时dba 无论怎么重启都会导致数据库宕机，进而导致整个服务挂掉，按照下面的现象图说明：其实缓存雪崩这类的问题，并不是再生产环境中一定会出，但是一旦出现之后，往往造成的影响是巨大的。
2023-05-20 15:20:34
67
1
原创 Redis_cluster 核心机制说明
基于重定向的客户端，很消耗网络IO，因为大部分情况下，可能都会出现一次请求重定向，才能找到正确的节点，所以大部分的客户端，比如java redis客户端，就是jedis，都是smart的本地维护一份hashslot -> node 的映射表，缓存，大部分情况下，直接走本地缓存就可以找到hashslot -> node ，不需要通过节点进行moved重定向。
2023-05-20 11:50:32
147
1
原创 Redis_cluster工作原理及分布式算法
自动将数据进行分片，每个master 上放一部分数据提供内置的高可用支持，部分master 不可用时，还是可以继续工作的在Redis cluster架构下，每隔redis要放开两个端口号，比如一个是6379，另一个就是加了10000的端口号：1637916379 这个端口号是用来进行节点间通信的，也就是cluster bus的东西，集群总线，cluster bus的通信，用来进行故障检测，配置更新，故障转移授权等等。
2023-05-19 16:41:58
130
1
原创 Redis数据的持久化
Redis中默认有两种持久化方式:RDB，AOFRDB 持久化机制，对redis中的数据执行周期性的持久化AOF机制对每条写入命令为日志，以append-onlyu的模式写入一个日志文件中，再redis重启的时候，可以通过回放AOF日志中的所有写入指令，来重新构建整个数据集如果我们想要Redis仅仅作为纯内存的缓存使用，那么可以禁止RDB和AOF所有的持久化策略如果同时使用RDB和AOF两种持久化机制，那么在Redis重启的时候，会使用AOF来重新构建数据，因为AOF 中的数据更加完整。
2023-05-19 11:46:02
166
1
原创 Redis主从复制的原理以及高可用性总结
Redis slave启动的时候，会根据config 中配置的master node 的ip, host,run_id等获取到master node 的信息等Slave node 启动成功之后，会根据上述的信息去ping master node 如果可以ping 成功，则与master 建立socket 连接连接建立成功之后，master node会与slave node 进行一次full resynchronization (全量复制)
2023-05-15 14:50:31
59
2
原创 Redis_Sentinal 核心概念说明
哨兵会监听mastrer节点状态，如果说此时Sentinal判断master node现在已经宕机，实际上是会有两种宕机状态: Sdown 和 Odown。
2023-05-15 14:12:08
95
1
原创 Redis数据丢失情况，解决异步复制和脑裂导致的数据丢失
脑裂，也就是说某个master所在的机器突然翻脱离了正常的网络，跟其他slave机器不能连接，但是实际上的master 还存活着，此时哨兵可能就认为master 宕机了，然后开启选举，将其他的slave 切换成了master , 这个时候，集群里就会有两个master,也就是所谓的脑裂。因为旧master再次恢复的时候，会被当做一个slave挂到新的master上去，把自己的数据会清空，强制同步新的Master节点数据。主备切换的过程中，可能会导致数据丢失。异步复制导致的数据丢失。
2023-05-15 11:27:21
555
1
原创 Redis复制的完整流程
master 和 slave 都会维护一个offset，master 会在自身不断累加offset,同时，slave 也会在自身不断累加offset, master 自身会保存每个slave 的offset，用来保存每次更新数据的具体位置，其实这个功能并不只是在全量复制的时候才会使用，而是在整个主从交互的流程中都在使用，这样才能识别到数据不一致的情况。master node在生成RDB时，会将所有新的写命令缓存到内存中，再Salve node保存了RDB之后，再输出新的写命令复制给salve node。
2023-05-14 18:06:26
149
原创 Redis不可用性以及基于哨兵机制的高可用性说明
如果你系统的服务端再全年99.99%的时间内都是可用的，那么这样的系统就叫做99.99%高可用性。
2023-05-14 17:44:43
84
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人