- 博客(30)
- 收藏
- 关注
原创 内部类解析
整理了一下内部类的相关知识,算是比较全,比较基础的,希望大家一起学习进步。在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关注的人