分布式专题
easyoh
努力,加油,向前
展开
-
RocketMQ如何处理消息丢失的问题,同步刷盘,异步刷盘,异步复制,同步双写
RocketMQ 消息持久化生产者向RocketMQ broker发送消息mq收到消息以后,会将消息持久化到硬盘,这样才能保证机器宕机重启后消息不丢失,仍然可以给消费者进行消费。这里有两种刷盘策略:同步刷盘、异步刷盘同步刷盘:也就是mq收到消息后,必须将消息持久化到硬盘以后才向Producer端返回ACK成功状态,这样就可以100%保证消息不丢失。除非硬盘也坏了。。。异步刷盘:mq收到消息后,将消息存入操作系统的OS cache里面,通过异步定时将消息刷入磁盘,这样可能会有少部分数据丢失,因原创 2020-05-16 20:40:51 · 1824 阅读 · 0 评论 -
分布式锁选型方案,Redisson和zookeeper curator 做分布式锁的优缺点
RedissonRedisson框架集成以后,可以指定一个keykey,通过lua脚本向redis加锁。加锁后,将会启动一个“看门狗”的后台线程,定时检测是否仍然持有锁,如果持有,将延长锁的持有时间其他需要获取该锁的服务,将不断循环获取该锁,直到前面的线程释放了锁为止。优点:redis性能很高,适合高并发下的加锁机制缺点:如果加锁的redis master 故障,刚好数据也还没有同步到slave,那其他加锁的客户端则会再次加锁成功,则相当于有两个客户大都拿到了锁。zookeep原创 2020-05-16 01:14:11 · 2742 阅读 · 0 评论 -
分布式事务方案怎么调研选型?TCC、seataAT、 最终一致性事务的原理和优缺点都有什么?
分布式事务一直是微服务等分布式系统不得不面对的难题。目前主流的解决方案有以下几种。基于阿里巴巴开源的seata AT模式分布式事务框架TCC 三段式提交事务方案(业界一般使用ByteTCC框架)基于RocketMq 消息中间件实现最终一致性事务下面基于这三种方式进行原理剖析对比选型以及各自的优缺点比较一、Seata二、TCC二、基于RocketMq实现最终一致性总结...原创 2020-05-14 23:02:53 · 5141 阅读 · 0 评论 -
产环境的服务是怎么配置超时和重试参数的?设置重试后如果解决幂等问题?
spring cloud gatewayRetryGatewayFilter 是 Spring Cloud Gateway 对请求重试提供的一个 GatewayFilter Factory。配置方式如下所示。spring: cloud: gateway: routes: - id: zuul-encrypt-service uri: lb://zuul-encrypt-service predicates: - Path=/data/** fi原创 2020-05-11 00:05:51 · 260 阅读 · 0 评论 -
你们公司的网关是怎么技术选型的,假设有高并发场景怎么优化?
微服务网关选择,一般是两种zuul和spring cloud gateway对比:zuul是Netflix的产品,gateway是spring全家桶的亲儿子。zuul 更新维护不积极,所以gateway自己做了网关,就是为了替代zuulzuul 1.0和 2.0差别很大,1.0版本是基于servlet的同步阻塞io,2.0是基于netty通信的异步io,并发能力2.0版本大大提升。但是2.0文档相对不友好。gateway本身是基于netty通信的异步io,并发能力很强。学习难度:gateway文原创 2020-05-10 23:08:24 · 730 阅读 · 0 评论 -
说一下自己公司的服务注册中心怎么技术选型的
CAP 理论C:一致性A :可用性P:分区一致性 (一定时间内完成一致性,避免造成分区数据不一致)一般只能保持CP 或者AP下面先来分析一下他们的优劣eurake缓存架构图eurake本身有缓存策略,本地注册表更新了服务的地址后,需要先同步至ReadWriteCacheMap,然后在同步至ReadOnlyCacheMap,然后其他服务就从ReadOnlyCacheMap里面拉去最新的注册表信息。所以在同步和拉取的过程当中,会有很多时间延迟。Eurake 采用的是peer to peer原创 2020-05-10 21:34:33 · 347 阅读 · 0 评论 -
Spring Cloud的架构原理图
原创 2020-05-10 15:12:03 · 145 阅读 · 0 评论 -
Dubbo的底层架构原理图
原创 2020-05-10 14:34:23 · 162 阅读 · 0 评论 -
你们的系统使用了哪种服务框架?为什么要这样技术选型?
前言如果将要系统进行服务化,必然会涉及到将整块系统拆分为一个个独立的小系统,也就是服务拆分。既然是服务拆分,必然会涉及到服务管理和服务调用等一系列的问题,所以,服务框架的选择将直接影响到后拆分后系统的稳定性,健壮性,开发的便利性。框架选择目前市面流行的服务框架一般是两个spring cloud 和 dubbo。但是从近来这几年微服务的大量流行,默认spring cloud的趋势越来越明显。下面开始这两个框架选型对比:功能对比spring clouddubbo并发性能spr原创 2020-05-10 00:06:54 · 329 阅读 · 0 评论