- 博客(14)
- 资源 (1)
- 收藏
- 关注
原创 Dubbo源码,详解dubbo协议数据包及解包过程
RPC协议即远程进程调用协议,自己的话理解就是,让两个进程之间的调用像同进程内调用一个函数那么简单。Dubbo框架的传输层默认使用dubbo协议,这也是...
2019-12-30 00:00:00 1330 1
原创 Netty源码,详解Http协议的数据包解码过程
Http全称为超文本传输协议,是一种无状态协议。即不会记录你上一次访问了什么。一应一答,一个请求一个响应,无需保持连接。在不保持长连接的情况下,一次ht...
2019-12-29 09:00:00 2249 1
原创 AWS SQS 消息中间件的好与坏
可见性超时如果设置得短,可能会出现消费者消费未完成,没有将消息删除的情况下,又被其它消费者拉取到,导致重复消费。是需要自己定时去拉取的。一是你不知道该由谁来删除这条消息,另一个则是,同一个消息可能会被同一个消费者消费多次,而也有可能有消费者一次都能不到这条消息。严格要求一条消息只能被消费一次的,除了在消息可见性超时上控制外,还需要在代码中控制消息的幂等性消费,而且是支持分布式集群的幂等性消费。是提供长轮询的,然后我再去看文档才发现文档写了支持长轮询,可能之前还没有,最近更新的,也可能之前我看文档没看仔细?
2019-12-28 11:34:56 1670 1
原创 Alibaba Sentinel是如何统计QPS实现限流的
我们项目中使用了Sentinel作为限流器,Sentinel可配置按最大工作线程数以及按QPS限流,而要实现这两个限流规则,就必须要统计到当前工作线程数...
2019-12-23 09:00:00 5171 2
原创 Spring事务的实现源码分析,以及事务不起作用原因分析
如果配置的PlatformTransactionManager事务管理器,使用的是一个动态数据源,那么TransactionSynchronizationManager会将这个动态数据源作为Key,因为多个数据源都是被动态数据源管理的,所以动态数据源内部怎么切换,一个事务中TransactionSynchronizationManager持有的都是第一次获取到的连接,整个事务中都会使用这个连接,因此在事务中切换数据源无效,应在事务之前完成数据源的切换。这是我的个人观察,看源码就是多吸收一些优秀的编程思想。
2019-12-22 00:01:49 487 1
原创 反向理解ThreadLocal,或许这样更容易理解
比如一个Spring项目,处理事务也是用的ThreadLocal,Dubbo的RpcContext也是用的ThreadLocal,处理一个请求通常都是在一个线程中去完成的,假设处理一个请求即用到Dubbo发起rpc调用,又用到事务注解操作数据库,那么至少就存在两个ThreadLocal 往一个线程Thread实例的threadLocals字段写数据。创建一个线程都是通过new Thread创建的,使用线程池也不例外,但不代表Thread的字段就是线程安全的,它也是一个普通的对象,也是分配在堆中。
2019-12-18 00:00:00 221 1
原创 Dubbo RPC远程调用过程源码分析(服务消费者)
上篇我们分析了服务提供者处理一个请求的全过程,当然,是跳过信息交换层和传输层的。本篇继续分析服务提供者发起一个远程RPC调用的全过程,也是跳过信息交换层...
2019-12-17 00:00:00 1123 1
原创 Dubbo RPC远程调用过程源码分析(服务提供者)
在前面分析Dubbo注册中心层源码的文章中,我们知道,服务的导出与引入由RegistryProtocol调度完成。对于服务提供者,服务是先导出再注册到注...
2019-12-16 00:00:00 2508 1
原创 Dubbo分层架构之服务注册中心层的源码分析(下)
基于Redis实现的注册中心为什么不被推荐使用,你知道原因吗?由于我在实际项目中并未使用Redis作为服务注册中心,所以一直没有关注这个话题。那么,使用...
2019-12-15 10:00:00 383 1
原创 Dubbo分层架构之服务注册中心层的源码分析(上)
服务注册与发现是Dubbo核心的一个模块,假如没有注册中心,我们要调用远程服务,就必须要预先配置,就像调用第三方http接口一样,需要知道接口的域名或者...
2019-12-14 13:28:04 446 1
原创 缓存雪崩、穿透如何解决,如何确保Redis只缓存热点数据?
缓存雪崩如何解决?缓存穿透如何解决?如何确保Redis缓存的都是热点数据?如何更新缓存数据?如何处理请求倾斜?实际业务场景下,如何选择缓存数据结构1缓存...
2019-12-12 10:00:10 238 1
原创 线上RPC远程调用频繁超时问题排查,大功臣Arthas
对外服务(下文统称服务A)处理终端一次请求的平均耗时在25ms左右,正常情况下并发量突增到服务所能承受的最高点时,最大耗时也在200ms以内,而一次请求中调用某个服务(下文统称服务B)的耗时必然会小于一次请求的处理耗时,所以我把服务A调用服务B的rpc调用超时设置为500ms,避免因调用阻塞等待导致请求堆积问题,所以本次服务崩溃并未看到文件句柄数达上限的异常,也因如此,只会有部分请求处理失败,不止于整个服务完全不可用。优化后,服务B的QPS有了显著的提升,像极了牙膏,挤挤又省几台机器。
2019-12-07 17:00:10 3143 1
原创 如何让JedisCluster支持Pipeline
hmset等批量操作命令与pipeline最大的区别是,前者是原子性命令,比如hmset,如果一次插入的field过多,会导致命令耗时增加;后者非原子性...
2019-12-02 09:00:00 1743 2
原创 Redis性能监控问题
并发数上升,到底是哪个服务处理能力到了瓶颈,还是Redis性能到了瓶颈,只有找出是哪里的性能问题,才能对症下药。所以,了解redis的一些运维知识能够帮...
2019-12-02 09:00:00 1298 1
IPv4-国家-区域-城市-运营商csv格式数据库-附使用java写的使用demo
2023-10-14
2019年毕业设计-一款情侣APP 附论文、作品视频演示、代码
2023-10-13
2019毕业设计作品-一款支持来电拦截的通讯录APP 附论文核心部分、项目代码
2023-10-12
Java堆外内存使用分析详细
2023-10-12
ArchSummit 2023 全球架构师峰会 北京站 PPT(公开)
2023-10-12
用c#实现的读取rtf格式文件的工具类
2016-01-21
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人