zhanglehes的专栏

在很多场景需要并发的去读写数据，如下图所示：考虑到数据写入的顺序性，通常只会有一个线程写入，读数据是可以多线程的。由于对于Data的一次写入不是原子操作，一个常用通常的方式就是在写的时候加写锁，读的时候加读锁。这在同一个线程每次读数据没有依赖时是可行的，否者还是可能出现问题。如在一次数据处理中，先通过用户“姓名”找到Data中对应的id，再通过id去Data中查找用户其它信息。在这两步之前，写线程可能已经把该用户从Data中删除了，这时就会出现异常。

代码编译过程中，为了防止同一份代码被重复引用，通常有两种实现方式方式一方式二#endif //!TEST_H通常情况下，使用上述两种方式中的任意一种都是可以的。最近工作中，代码按照其功能性被划分出不同的模块，这时二者的区别就体现出来了。

设计表初期，也需要考虑数据增长的问题，当数据量增长过快时，可以将部分bucket中的映射关系改到新增的表中，然后再对原有的数据进行迁移。本人多年前也遇到过数据量巨大的项目，使用单mysql表读写性能非常的差，后来经过调研，使用了hbase存储加上spark计算的方式，存储效率和计算效率都得以巨大的提升，效果可以说是非常的好的。二是运维成本也较大，hbase底层使用hdfs进行数据存储，spark也是基于内存的并行计算框架，对资源的消耗都是巨大的。那么对于无限增长的数据，有什么简单又可靠的存储方式么？...

很多服务依赖数据版本迭代。如搜索系统，每天会产生一个全量索引版本。路网系统，每天会加载新版本的路网数据。一个简单的做法是每次更新数据版本时，都停止服务，重新加载最新的数据（通常在流量最低的时间点）。但这种做法显然不够优雅。更常用的方案是加载双版本数据，动态切换，而不需要停止服务。本文介绍这种方案的一种实现方式。...

微服务的广泛应用，使得模块间功能划分更加清晰，代码可维护性高。但并不是说微服务的运维成本更低了。假设原先是一个单体服务，我们将它进行微服务化的改造，拆成了多个服务，这时一旦下游服务出现问题，整体服务也会受到影响。兜底策略是在整体（微服务）系统出现问题时，仍然尽可能去保障服务的可用性（通常以一定数据精度损失作为代价）。...

目前维护的一套c++服务，在打印日志时会存在锁竞争。先用brpc定位锁竞争的环节，然后提出集中改进方案，以及它们的优缺点。使用brpc在压测环境下打印contention火焰图。左边的圆圈是处理服务的接入数据，会记录接收量，os类型，业务方类型等统计参数；右边那两个稍小圆圈是两处发送下游，会记录发出量等统计参数；它们都是用同一把锁，当需要写入统计数据时，会去竞争这把锁；从连接方框的边旁的数据大小，可以看到主要的锁竞争来自于处理接收数据的业务函数。原因是我们的服务接收数据是逐条接收的，但是发送数据是批量，因此

之前我写过一篇文章，介绍微服务框架下如何打印日志 -- 微服务下的日志打印标准_zhanglehes的博客-CSDN博客_微服务日志traceid虽然通过日志记录，我们可以获取到任何时刻的异常情况。但是打印日志毕竟是一种“被动”行为，当线上服务出现问题时，我们需要一种主动通知的机制。这就是报警。通常有两种报警通知的设计模式。一是日志收集，在服务器上有个log-agent，通过事先制定的正则表达式去匹配服务打印的每行日志。一旦匹配上，会统计相关参数，发送给消息队列，最后数据被灌入数据库中。二是metrics上

灰度发布我们通常在两种场景下使用灰度发布：一是新功能上线后先对内部用户开发测试，二是按流量逐步扩大访问新功能。通常我们提到的小流量上线可以分成两种方式。一是只有部分服务器上线新功能，所有打到这些服务器上的流量将访问到新功能，所有打到未上线服务器的流量使用老功能。二就是灰度实验，这种方式新功能会上线到所有的服务器上，在代码中使用if else的方式，选择性的使用新功能。使用第一种方式通常在稳定性验证、或者性能验证阶段，通常持续时间不长（一天左右），对验证流量无法进行选取。使用第二种方式是在已经验证

概要Reader是暴露给应用程序的接口，前一章提到的Consumer Group是集成在本类型中使用的。之前提到的Consumer Group主要处理消费topic的相关metadata信息，如relabance，commit offset，heartbeat等。而Reader类主要负责从kafka brokers中拉取数据。Reader有两种使用模式，一是单topic单partition的情形，由Application自己去管理offset的信息；而是Consumer Group的情形。因此在代码

概要本文主要介绍一些kafka内部原理概念，包括controller，Coordinator，patition，storage，produce和consume。PatitionsPatition是kafka实际的存储单元，topic只是Patition的一个逻辑集合。Patition分为leader和followers，它们是由controller进行的分配。Patition又分为isr（in-sync replica）和osr（out-sync replica）；isr是表示leader

作用为redis服务提供了高可用性，在不需要人为干预的情况下，能抵御某些redis服务的失效，并自动修复。除了redis集群的自动修复功能外，Redis Sentinel同时提供了一些其他的功能，例如：监控（主从个数等）、通知（通过api的方式通知某些失效的信息）、并为client提供（master）配置信息（类似于dns的作用）。Sentinel本身是一套分布式系统Sentinel的主要功能是通过redis的多副本的方式，保证在有instance失效的情况下，整个redis集群的可用性

简介grpc是一个高性能、开源、通用的RPC框架，由Google推出，基于http2协议标准设计开发，默认采用protocol buffer数据序列化协议，支持多种开发语言。gRPC提供了一种简单的方法来精确的定义服务，并且为客户端和服务端自动生成可靠的功能库。本文主要介绍除了基本的rpc通信功能外，grpc支持的扩展功能。认证gRPC默认内置了两种认证方式：SSL/TLS认证方式（对服务端认证） 基于Token的认证方式（对客户端认证）同时，gRPC提供了接口用于扩展自定义认证方式

概要单体服务的日志打印比较简单，因为一条请求的所有流程都在单体服务中。相反，一条请求在微服务系统中会经历若干服务，在任何一个服务中都可能出现问题，因此记录的错误原因会分散到不同的地方。我们可以使用ELK来收集日志，将其存放在es或者hive中，这样方便查询。本文主要介绍日志在微服务系统中的标准格式。流程图TraceId与SpanId一条请求涉及的所有日志是通过TraceId来表示标识其唯一性的。SpanId能提供如下作用：1、该服务在请求中的调用层级；2、调用顺序关.

概述本文主要讨论从http1.x协议到http2.0协议的通信方式发展历程连接的四种模式一次请求一个tcp连接每次都需要新建连接连接池对于底层连接的复用，降低第一种模式下建立tcp连接的时间开销。之前的博客有分析过这种连接模式的源码 --Golang Http RoundTrip解析_zhanglehes的专栏-CSDN博客Pipelining它是一项浏览器的技术，在1.1版本中提出了协议标准。其基本思想是当一个网页中包含多个对象是，使用pipelining技术.

Router1、支持POST,GET,PUT等多种方法，实现如下：type methodTree struct { method string root *node}type methodTrees []methodTreefunc (trees methodTrees) get(method string) *node { for _, tree := range trees { if tree.method == method { return tree.r

代码https://blog.csdn.net/jfwan/article/details/109328874原理与代码分析核心参数Total – 向下游发送的总请求量Accept – 下游能正常返回的请求量在算法设计中，Total和Accept之前存在一个倍数，当total大于Accept乘以倍数，则表示下游服务出现异常，熔断功能打开，否则会将请求直接发往下游服务。这个倍数就是下面结构体中的参数k。type googleBreaker struct { k floa

本周在做运营平台的限流方案设计，整理如下。概要目前运营平台并无限流功能。带来的结果是：有爆款活动上线时，需要提现扩容，防止服务被高并发流量给打挂掉； 不同业务活动会相互干扰，特别是当有些活动被恶意攻击的情况下；我们希望在极端情况下，运营平台的业务功能仍能得到部分保障。业务现状目前运营活动的请求通常来之三端，分别是NA（ios、android），独立小程序和主小程序； 运营平台同时提供了部分基础功能（如赶车闹钟设置），供公司内部其它服务使用； 不同的活动通过activity .

定义（底层视角）单一功能避免单个服务的代码量过大（代码量对于业务迭代、维护的影响较大） 各服务间定义清晰的边界（解耦合），易于任务的拆解服务自治各服务可以搭建在异构体系之上 各服务允许使用不同的技术栈 定义明确、合理的API，服务内部调整不应该影响上下游优势技术栈多样化，容易吸收技术，技术更新成本较小 健壮性更佳，可以降低单个问题服务对整体的影响，服务可降级 扩展性更佳 易于部署，降低故障概率，提升部署效率 服务组件化，可复用 业务迭代更快，不容易出现“不可维护代码”.

最近使用memcached做了一个缓存系统，其基本架构是duo

本篇主要介绍分布式框架的模块和其主要使用的通信方式zmq。首先，对于任意的上游结点，它都有可能会把处理的结果发送到任意的一台下游结点中，同时如果下游结点有新增的结点，上游结点还能自动感知并处理。另一方面，任意的下游结点也会要和所有的上游结点保持心跳。如果使用原始的socket，解决上述的问题会比较麻烦，所以我们运用了zmq来解决上述的问题。Zmq具有下述的优点：1. 是一个跨协议的通信方式，目

通常，当服务涉及到的数据量大到一定程度以后，我们会考虑拆分数据。在这种分布式架构中，每个结点只拥有总数据量的其中一部分，而最终的输出结果会汇总所有结点的结果。这种Map-reduce思想的架构，是尽量不去查分程序，而只是拆分数据来支持大数据的处理，如下图所示。这种框架对每个worker结点的可靠性要求比较高，如果某一个worker结点挂掉了，那么最后的输出结果将是不全的。我设计的这个分

我们设计的分布式系统，在正常工作时呈现出网状。服务有层次性，客户的请求会逐步经历各层服务进行处理，当遍历完所有服务后才会完成一次请求。每层服务会有若干台机器，上游节点的机器可以把输出结果传递到下游节点的任意一台机器上。 当服务所依赖的数据需要更新时，我们需要做好同步工作，并保证在数据更新过程中服务是可用的。这儿介绍两类更新的操作方式，它们都需要用到zookeeper来实现。 第一类

本文讨论在分布式框架中使用到的两个数据结构。为了实现高性能，这两个数据结构都是无锁的。第一个数据结构存储的是客户端发过来的socket。由于我们的框架只有一个线程接受用户的请求，所以很容易对每一个socket创建一个unique number（稍候我们再来看unique number包含了哪些信息）。框架中有一个线程专门来做清理工作，同时关闭没有返回给客户端的socket。最后框架中有多个线程

1、WebAPI的设计规范1.1restfull协议（标准的操作类型，层级资源关系设计，分页设计、属性排序、筛选设计等）1.2良好接口设计1.2.1客户易学习，有完善的文档及提供尽可能多的示例和可copy－paste的代码(samplecode)；1.2.2客户易使用，没有难理解或易误解的细节，易于学习。灵活的API允许按字段排序、可自定义分页、排序和筛选等；1.2.3一...

转至元数据起始监控项 名称 持续时间 严重等级 表达式 解释 high_cpu_load 1m warning node_load1 > 50 负载超过50后开始报警 high_memory_load 1m warning （...

目标那么错误码能为我们带来什么？首先，通过错误码我们能识别出系统到底出了什么问题？其次，通过错误码我们应当能识别出哪个系统出了问题？再次，通过错误码需要知道对应的定位问题和解决问题的方法。最后，通过错误码我们可以决策出该给客户显示出了什么问题？（前端）使用方PaaS集成商，负责运维我们的服务； SaaS应用层服务； 地平线部署人员、客服人员；错误码分类 ...

目的目前xid使用的是全比对的方式，也就是每张图片的特征值会和底库中每张图片的特征值进行比较，然后打出一个相似度的分数；目前比较过程是cpu并行完成的，本文尝试使用在相同过程的提速效应；使用nvdia的cuda并行计算框架；环境host :gpu001.hogpu.cccpu的物理指标：? processor : 0 vendor_id...

概要源于facebook的faiss库，其用过GPU 对于进行加速，另外xfr中也用到GPU，而需求源于之前xid对于大数据量的性能问题。之前也了解过一些机器学习的平台，如tersorflow，paddlepaddle，他们均将GPU加速作为平台的一大“卖点”。因此思考GPU编程对于智能基础服务还是有很大的帮助，于是“贸然”涉足了这一领域。CUDA编程给我的感觉是 1. 入门很容易，我大概...

为什么要提供控制台我们的产品是以PaaS平台为主，辅以轻量级的SaaS，以私有云部署为主。当用户拿到我们产品后，如果不提供一套页面工具，用户无法确认我们的系统是否正常启动，IPC是否正常连接到系统等。因此我们需要提供一套控制台界面，让用户可视化的感知我们的系统。从功能上讲，控制台提供的服务需要区别于PaaS服务，PaaS更多是从应用我们的服务出发提供的接口，而控制台更多的是从管理我们设备和系统...

比如一个job需要处理N个tasks，每个tasks之间wanqua