0102的博客

【代码】Interview preparation-- Feign源码分析。

Kafka中是通过Zookeeper选举的出的Master/Slave，Zookeeper具备选举功能，选举机制的原理是少数服从多数，那么Zookeeper的选举机制必定由Zookeeper集群中多个实例共同完成，Zookeeper集群中多个实例必须相互通讯，如果实例太多，网络通讯就会变得非常复杂，并且zookeeper在自身master挂掉，发生选举master节点期间是不对外提供服务的，这样的话系统会变得非常复杂。RocketMQ中Topic是逻辑概念，队列（Queue）是物理概念，和Kafka很想。

事物完成后释放锁等资源，删除日志。AT模式是一种无侵入的分布式事务解决方案，用户只需要关注自己的SQL，AT模式中用户的SQL就是第一阶段，Seata-AT模式会给你自动生成事务二阶段提交与回滚，是2PC的一个应用。一阶段：Seata拦截业务SQL，解析SQL，找到要更新的数据，记录Undo，然后执行业务SQL，在记录Redo，最后生成行锁，这些操作都是在本地数据库事务内完成。2PC即两阶段提交协议，是将整个事物流程分为两个阶段，P是指准备阶段，C是提交阶段。

自定义Filter 用的才是最多的，需要实现Ordered，GlobalFilter。

下图是令牌桶案例，系统已一定速率（r token/sec）往固定容量的令牌桶中放入令牌，如果此时有客户端请求过来，则需要从令牌桶中拿到令牌以获得访问资格。令牌桶是对网络整体限制 + 速率限制的一个常用算法，对于每一个请求，都需要从令牌桶中获取一个令牌，如果没有获得令牌，则需要出发限流策略。令牌桶算法中，有两个关键值，桶容量，令牌添加速率，两个值都必须低于系统能承载的最大QPS，

Sentinel的设计中资源定义和 规则配置，还有流控算法三者是分开的，我们可以通过Sentinel api先定义好资源埋点，然后需要的时候我们在实时的增加上流控规则。这种方式极大的增加了Sentinel的灵活性。Sentinel是一个轻量级的流控架构，主要以流量为切入点，从流量控制，熔断，系统负载保护等多个维度来帮助用户保护服务的稳定性。与Hystrixx相比，Sentinel设计更简单，使用更方便灵活，能动态的修改限制规则。

服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存。Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。

​ CP 原则属于强一致性原则，要求所有节点可以查询的数据随时都要保持一直（同步中的数据不可查询），即：若干个节点形成一个逻辑的共享区域，某一个节点更新的数据都会立即同步到其他数据节点之中，当数据同步完成后才能返回成功的结果，但是在实际的运行过程中网络故障在所难免，如果此时若干个服务节点之间无法通讯时就会出现错误，从而牺牲了以可用性原则（A），例如关系型数据库中的事务。​ 分区容错性（Partition tolerance）：在网络异常（光缆断裂、设备故障、宕机）的情况下，系统仍能提供正常的服务。

问题排查针对各种常见的线上问题，梳理下排查思路。业务问题线上问题大多数时候都是业务问题引发的问题，当线上环境绝大多数请求都是正常，当有部分或者某一个用户有问题，此时怎么针对性的排查在当前微服务体系下，一般都会有分布式链路追踪系统 ，以及ELK日志系统，我们完全可以通过监控平台去找到问题的点：异常日志的抓取此时我们可以通过日志追踪得到当前用户的请求信息：利用Arths的watch命令监控对应异常接口，通过日志得到对应的参数，通过Dubbo的invoke 命令模拟线上用户的请求，

问题:大规模数据如何检索当系统数据量达到10亿，100亿级别的时候，我们系统该如何去解决这种问题。数据库选择—mysql， sybase，oracle，mongodb，hbase…单点故障如何解决—lvs， F5，A10，Zookeeper，MQ如何保证数据安全----热备，冷备，异地多活如何解决检索难题—数据库中间件mysql-proxy，sharding， cobar， MaxScale如何积极统计分析问题—离线计算，近实时传统数据库的应对解决方案，对于关系型数据库，通常用以下架

Seata AT 模式上一节中我们提到AT模式是基于XA事务模型演变过来的，所以他的整体机制也是一个改进版本的两阶段提交协议。第一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和链接资源第二阶段：提交异步化，非常快速完成。回滚通过第一阶段的回滚日志进行反向补偿接下来会解析整个执行流程中每一个阶段的具体实现 原来。同时为了更好的理解AT模式的工作机制，我们以产品表za_product来描述整个流程，表结构如下：CREATE TABLE `za_product` ( `i

seata上一篇：分布式事务解决方案

分布式事务解决方案之前一节分析了分布式事务的问题以及理论模型，并且基于CAP理论，我们知道对于数据一致性问题有AP和CP俩种方案。但是在我们实际项目中局域CP的强一致性在数据库性能与系统处理能力上会有很大的制约。所以我们实际项目中更多的采取柔性事务。“柔性事务”是遵循BASE理论来实现的事务模型，他有两个特性：基本可用，柔性状态（状态段时不一致）。TCC补偿方案TCC（Try Confirm Cancel）是一种比较老的分布式一致性解决方案，他实际上是将完整的业务拆分成一下三个步骤。Try

分布式事务上一篇：SpringCloud Alibaba 框架下公司架构图

上一篇：Docker容器实战思维下一篇：分布式事务理论模型

Docker数据管理

SpringCloud常见问题总结(一)

Eureka常见问题Eureka注册服务慢默认情况，服务注册到Eureka Server 的过程比较慢。在开发或者测试时候，如果能够加速注册的过程，从而提升工作效率。Spring Cloud官方文档详细描述了该问题的原因并提供了解决方案：//原文Why is it so Slow to Register a Service?Being an instance also involves a periodic heartbeat to the registry (via the client’

背景日志系统主要包括系统日志，应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器的软件，硬件信息，检查配置过程中的错误以及错误发生的原因。通常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。难点一：通常日志被分散在不同设备上，如果你管理数十台上百台服务器，你开在使用一次登录每一台机器的传统方法查询日志，效率明显低下。我们应该使用集中化的日志管理，例如：开源的syslog，将所有服务器上的日志收集汇总。难点二：集中化管理后，日志系统的统计检索又成为一件比较麻

分布式锁分布式系统进行逻辑处理的时候，经常会遇到并发问题，例如直播场景中，用户需要连麦主播，当多个用户在同一个时刻一起连麦时候，应该保证只有一个用户能连麦成功，我们改怎么保证这种业务场景下保证数据的正确性。当我们连麦的时候，其实设计到两个步骤操作，首先读取房间座位信息，当发现座位没有被占用，修改作为状态，之后存储。但是这几个步骤并非原子操作，也就是可能存在两个线程同时读取，一起修改，这样肯定会造成数据错乱。怎样来保证读取，修改，存储，这三个步骤的原子操作就是分布式锁需要解决的问题。分布式锁的奥义

上一篇Redis基础数据结构内部实现简单介绍

5种基础数据结构Redis有5种基础数据结构，分别是：String（字符串），list（列表），hash（字典），set（集合），zset（有序集合），这五种是我们开发种经常用的到的，是Redis种最基础，最重要的部分。string（字符串）字符串string是Redis最简单的一个数据结构，他的内部表示是一个字符数组，Redis所有的数据结构都以唯一的key字符串作为名称，然后通过这个唯一的key获取对应的value数据，不同类型数据结构差异其实就在value上而已。如下图对应String类型

上一篇Zookeeper–分布式锁实现

上一篇Zookeeper实践与应用-- Nginx负载均衡差异

Zookeeper实践与应用- Canal

下一篇Zookeeper实践与应用- Canal

待续下一篇Zookeeper实践与应用- Canal

线上事故复盘前言前一次上线，当时正常，第二天发现有部分超时报警，最终发现应为Dubbo接口一次传输数据量太大导致线程虚拟内存占用线上问题排查过程报警邮件中查询到有一部分接口超时量激增，查询定位到某个Dubbo接口，从服务器中top名查询如下：如上图显示dubbo项目进程CPU占用已经飙高到128%，并且不断在波动，一直维持在130%左右，初步推算是调用量激增导致Dubbo接口请求量变大，导致线程数量消耗，使用Arthas查询消耗CPU资源最多的前面几个线程如下图：图不见了： 反

基于MySql BinLog的增量订阅和消费组件：CanalCancal是阿里13年1月开源的一个基于MySql数据库Binlog实现的增量订阅和消费的组件。项目取名Canal取自管道的英文单词，流转的医生，是一个定位于基于MySql数据库Binlog增量日志来实现数据库镜像，试试备份和怎梁书记消费的通用组件。早期的数据库同步业务，大多使用MySql数据库的触发器机制（Trigger）来获取数据库的增量变更，之后逐步阐释基于数据库日志解析来获取数据，再次激起上实现数据同步，由此衍生出了数据库增量订阅和

待续

ZAB协议Zookeeper并不是完全采用Paxos算法，而是使用了一种称为Zookeeper Atomic Broadcast（ZAB，Zookeeper原子消息广播协议）作为数据一致性的核心算法，依据此算法来实现分布式数据一致性的解决。他是一种特别为Zookeeper设计的奔溃可恢复的原子消息广播算法。ZAB协议的核心是定义了对应那些会改变Zookeeper服务器数据状态的师傅请求的处理方式：所有事务请求必须有一个全局唯一服务器来协调处理，这样的服务器被称为leader服务器其他服务器成为f