weixin_47202589的博客

Logan分布式改造&OSS上传优化 背景 logan是美团开源的一个日志回捞系统，日志文件在默认在本地存储，到上报用户增多时，单机性能到达瓶颈，需要升级架构，改造为分布式。 问题 日志文件的共享 防止重复解析日志文件 解决方案 日志文件存储方式采用对象存储OSS 解析日志文件增加redis分布式锁 详情 客户端上报的日志分为两种，1是手动回捞的日志，2是客户端奔溃上报日志。日志文件是加密的压缩文件，上传到服务端以后，需要进行解压解密，然后上传存储到oss。日志文件解密解压过程，是以‘\1’

分布式锁原理图 Code 实现 Lock.java public interface Lock { void getLock(); void unLock(); } AbstractLock.java public abstract class AbstractLock implements Lock{ @Override public void getLock() { //竞争锁 if(tryLock()){

初识Zookeeper Zookeeper提供了一个高性能、高可用，且具备严格的顺序访问控制能力的分布式协调服务。 简单的数据结构，树形结构，类型Linus文件系统。 顺序访问，对于每一个读请求，zk会分配一个全局唯一的递增编号。 高性能，数据存储于内存（笔者认为就是一个内存型树形数据结构数据库）。 常见场景 数据发布订阅 负载均衡 命名服务 Master选举 集群管理 配置管理 分布式队列 分布式锁 进入正题集群搭建 环境搭建 准备3台虚拟机，安装好docker-compose，拉取zookeeper

两阶段提交（2PC） 优点：尽量保证了数据的强一致性，各大主流数据库本身支持（XA协议） 缺点： 单点问题：阶段一完成以后，事务管理器宕机，导致无法进行阶段二，资源管理器一直处于阻塞状态。 同步阻塞：阶段一完成以后，所有的资源管理器都属于阻塞状态，直到事务提交或回滚才能释放资源。 数据不一致：在第二阶段中，事务管理器发送commit指令，由于网络等原因，部分资源管理器没有收到指令，导致数据不一致。 总结：2PC由于锁定资源时间长，对性能影响大，基本不适用分布式事务问题 三阶段提交（3PC）

redis配置中心原理篇 实现思路 所有的配置数据（xx.properties,xx.yml）都存储在环境变量Environment中，更改配置其实就是更改Environment中的属性值。 在单例bean中的@Value注解配置的属性值如何实现动态更新？单例bean只创建了一次，其余取值都是从singleObjects缓存中拿取。 如何解决这个问题？当然可以用多例，我们也可以自定义Scope。 更新完Environment环境变量以后，刷新带有我们自定义Scope的BeanDefinition

基于redis分布式配置中心 基于redis分布式配置中心 常见的配置中心有spring-cloud、dubbo、zk、nacos等，都需要引入第三方中间件，如果项目比较小，只是为了实现配置中心而引入中间件，有点得不偿失，增加维护成本；redis在大多数引用中都有使用，基于这一背景产生了此项目。 通过redis hash,PubSub实现动态更新@Vaule,Environment等配置属性值功能。 项目介绍 采用spring-boot-stater方式接入，实现了低耦合，便于开发管理。 应用启动自动加载配