iUcool的博客

本文为阅读笔记kafka通过利用分区来在多个队列中分配消息来实现并行性。然而每条消息都有不同的处理负载，也具有不同的消费速率，这样就有可能负载不均衡，从而使得瓶颈、延迟问题和整体系统不稳定，进而导致额外的维护工作或额外的资源分配。在 Kafka 中，分区器和分配器策略会影响消息分发。Producer 分区器Consumer 分配器这些策略都是基于两个主要的假设。

根据不同的应用场景和需求，可以选择不同的流式抽样方案。如果需要高效且简单的实现，可以考虑确定性哈希抽样或布隆过滤器方案；如果对数据量和性能有更高要求，Redis HyperLogLog和分层采样则是更合适的选择；对于需要时间维度分析的场景，可以使用时间窗口 + 一致性哈希方案。

对于一金额字段，由于会高频更新字段金额（一秒上百次），该如何设计技术方案处理可能出现的性能、一致性问题呢？

之前在某平台看到一篇有意思的场景——对于高并发读多写少场景下，如何进行高效键查询与统计早于其创建时间且没有被删除的数量（只需要先入先出，不需要从中间删元素）传统的数据库索引或简单的哈希存储难以同时满足这两个需求，尤其是在高并发环境下，如何在不影响查询效率的前提下维持顺序统计成为关键挑战。

以 TF - IDF 为例，如果文档中某个词出现的频率高（词频高），但在整个语料库（索引中的所有文档集合）中该词比较少见（逆文档频率高），那么这个词所在的文档相关性得分就会相对较高。例如，在一个美食相关的索引中，如果 “全聚德烤鸭” 这个词在某篇介绍全聚德的文档中多次出现，而在其他文档中很少出现，那这篇文档在以 “烤鸭” 为查询词时相关性得分就会比较高。是一个不变的、独立的倒排索引，储存了文档的字段、倒排表、储存字段以及其他索引元数据。分片会从它的所有 Segment 中收集匹配的文档，并按相关性排序。

此外在哨兵故障检测之外还存有节点自检，目的在于确保节点间通信正常，维护集群状态。以保证其他主节点知晓该主节点已经下线，并且防止从节点同时启动选举。如果手动配置新主节点或者槽迁移恰好碰上了故障选举，使得同一选举期存在多个主节点，那么该如何处理冲突呢？从节点会计算选举期，若获取的票不在本轮选举中，则不会进行计数。NodeID字典序更小的节点将成为唯一的主节点，并递增选举期。若故障节点为主节点，集群尝试从主节点的从节点中选取新主节点。会不会存在一个从节点收到了同主节点的两轮选举的投票呢？主节点在投票一次后，在。

PacificA是微软实现的强一致性的分布式共识协议，用于局域网中基于log的大规模储存系统遵循以下原则有以下前提条件系统仅发生fail-stop错误fail-stop是系统组件仅停止运行，而没有其他额外的错误行为消息可能丢弃或者重排，但不会被修改网络分区也可能发生不同服务器上的时钟不一定同步，甚至不一定是松散同步的，但是时间漂移有上限。

考虑到redis主从同步集群中，如果从master获取到锁之后，就故障换成了从节点，那么就会导致锁失效，因此提出了RedLock的分布式锁算法。该算法依赖于这样的假设:虽然进程之间没有同步时钟，但每个进程中的本地时间几乎以相同的速率更新，与锁的自动释放时间相比，误差很小。在上述锁中，存在一个问题——如果A获取了锁，但是由于执行时间过长，导致B也获取到过期后的锁，此时并会同时存在多方获取锁。以下是删除特定value的锁的lua脚本，这样就可以防止删除不属于自己的锁。在锁竞争比较激烈情况下，性能损耗较大。

若一组任务堆积量太大，或者堆积时间太长，则让其他工作节点每处理完一批本组数据，便要处理该堆积数据，直到该堆积数据低于阈值量或者阈值时间。设置一个批次插入为一个任务，在此定每次插入1000条数据，那么每个文件总共就是1w个任务，这1w个任务便为一个任务组。工作节点收到数据后，连接数据库，根据负载情况开启多线程对所接收任务，以任务ID组合行数作为表id进行插入数据。工作节点完成本节点绑定的所有任务之后，便可以开始抢占其他节点任务，以未完成量最多的任务组为优先。超过该任务数，进行抢占其他任务组或者等待。

如何记录请求经过多个分布式服务的信息，以便分析问题所在？从上文可知通过引入span和trace分别从被追踪者和请求链路两个维度，推断追踪树，从而用于分析问题如何保证这些信息得到完整的追踪？只要采样的绝对数量够大，那么就比较好追踪。对于分布式的情况，通过span组织的逻辑链路来达成；对于异步，关联到相关的线程；如何尽可能不影响服务性能？分析收集可以通过动态的开关来保证紧急情况下的性能稳定，而追踪主要是通过尽量减少采样保证的。

Service 是 将运行在一个或一组pod上的网络应用程序公开为网络服务的方法。定义service前端为service名称、ip、端口等不变的部分，后端为符合标签选择的pod集合。

Kubernetes(k8s)是用于自动部署、扩展和管理“容器化应用程序”的开源系统k8s由control plane以及cluster nodes构成。

分布式事务是为了保证不同数据库数据一致性。

分布式编程大部分都是在处理以下两个限制带来的结果这也就意味着传播永远会存在延迟，只是延迟多少的问题。并且分布式中节点都是独立的，那么很难像处理单体那样去处理分布式中的问题，比如我们无法像单体应用那样debug打断点。长期以来都是通过引入全局总顺序来保证强一致性然而这种顺序的保证却是相当昂贵的，需要不断和其他节点进行沟通，这会导致本应该服务于用户的资源用来做更多保证分布式一致性的工作了这种类型的系统保证了结果收敛到公共值，相当于一些正确的执行顺序。

保证消息发送顺序难点来自于分布式系统下，时钟不一致，没有全局时钟多个客户端、服务器之间的时钟可能大相径庭多客户端，导致接收顺序不一定在绝对时序上，若client1先发出msg1，而后client2发出msg2，那么是无法保证msg1一定先于msg2到达服务集群，难以协调消息顺序在绝对时序上，若client发出msg1，而后client发出msg2，那么由于服务器集群存在，是无法保证msg1一定先被接收处理网络传输与多线程，不保证传输和处理顺序。

拥有类似配置的计算机是一项艰巨的任务。网络拓扑并非一成不变，原本ip可能为192.168.2.1的机器可能等下就会变成192.168.2.2，原来只有3台机器的集群可能就会变成10台…在分布式系统中即使一个网络节点本身发生故障概率非常低，可是当节点足够多的时候整个分布式系统网络发生故障的概率就不可忽略了。带宽与延迟是天平上的两端，这要求我们需要尽量平衡两者。一次传输更多的数据缓解了延迟的问题，然而却带来了更高的带宽占用。要尽量使分布式系统更容易被监控，并解耦与其他组件的管理，这将使得系统更容易被管理。

向量时钟不仅同步本进程的时钟值，而且还同步已知的其他进程时钟值分布式系统中每个进程Pi保存一个本地逻辑时钟向量值VCi，VCi(j)代表进程Pi知道的进程Pj的本地逻辑时钟值那么如何证明VC(a) < VC(b) 可以推导a → b呢？如果事件a、b在同一个进程，那么肯定a->b如果事件a、b分别在进程Pa和Pb中那么设c为发送a更新事件，d为接收a更新时间因此可得VC(a)b。

raft是一种旨在替代Paxos系列的共识算法，比Paxos更加容易理解Raft不是拜占庭式的容错算法:节点信任选出的领导者raft通过选举的leader实现共识。在raft集群的服务器要么是leader要么是follower，并且follower能在leader不可用时竞选leaderleader负责将日志复制到follower，并通过发送持续的心跳告知follower自身的存在。当一个follow没在规定的时间收到leader的心跳，该leader便会开始参与竞选。

protoBuffer主要编写相应的数据结构以及接口方法定义package pd;// 因为rpc方法参数不能为空，所以定义一个空message}// 产品}// 因为所有参数都只能为message类型，所以对于prodId还是要定义为message}产品服务定义如下package pd;// stream就是前文介绍的流}当我们运行protoc命令之后，就会为我们自动生成pb.go文件。