PRC核心原理四

RPC 是解决分布式系统通信问题的一大利器,而分布式系统的一大特点就是高并发,所以说 RPC 也会面临高并发的场景。在这样的情况下,我们提供服务的每个服务节点就都可能由于访问量过大而引起一系列的问题,比如业务处理耗时过长、CPU 飘高、频繁 Full GC 以及服务进程直接宕机等等。但是在生产环境中,我们要保证服务的稳定性和高可用性,这时我们就需要业务进行自我保护,从而保证在高访问量、高并发的场景下,应用系统依然稳定,服务依然高可用。

那么在使用 RPC 时,业务又如何实现自我保护呢?

我们可以将 RPC 框架拆开来分析,RPC 调用包括服务端和调用端,调用端向服务端发起调用。下面我就分享一下服务端与调用端分别是如何进行自我保护的。

服务端的自我保护

我们先看服务端,作为服务端接收调用端发送过来的请求,这时服务端的某个节点负载压力过高了,我们该如何保护这个节点?如下图所示例:

负载压力高,那就不让它再接收太多的请求就好了,等接收和处理的请求数量下来后,这个节点的负载压力自然就下来了。在 RPC 调用中服务端的自我保护策略就是限流

Read more
PRC核心原理三

通过前面两章,一个点对点(Point to Point)版本的 RPC 框架就完成了。我一般称这种模式的 RPC 框架为单机版本,因为它没有集群能力。所谓集群能力,就是针对同一个接口有着多个服务提供者,但这多个服务提供者对于我们的调用方来说是透明的,所以在 RPC 里面我们还需要给调用方找到所有的服务提供方,并需要在 RPC 里面维护好接口跟服务提供者地址的关系,这样调用方在发起请求的时候才能快速地找到对应的接收地址,这就是我们常说的“服务发现”。

另外对于PRC,还需要服务治理的功能,比如服务提供方权重的设置、调用授权等一些常规治理手段。而服务调用方需要额外做哪些事情呢?每次调用前,我们都需要根据服务提供方设置的规则,从集群中选择可用的连接用于发送请求。

那到这儿,一个比较完善的 RPC 框架基本就完成了,功能也差不多就是这些了。按照分层设计的原则,我将这些功能模块分为了四层,具体内容见图示:

服务发现

在集群中,集群里面的这些节点随时可能变化,提供服务的节点增加或者减少,需要通知给调用方。这个过程叫做“服务发现”。

Read more
PRC核心原理二

上一文中介绍了什么是RPC,以及PRC的协议设计和对象序列化,详情可学习,本篇重点介绍PRC的网络通信和如何实现本地方法调用。

网络通信

常见的网络 IO 模型

那说到网络通信,就不得不提一下网络 IO 模型。为什么要讲网络 IO 模型呢?因为所谓的两台 PC 机之间的网络通信,实际上就是两台 PC 机对网络 IO 的操作。

常见的网络 IO 模型分为四种:同步阻塞 IO(BIO)、同步非阻塞 IO(NIO)、IO 多路复用和异步非阻塞 IO(AIO)。在这四种 IO 模型中,只有 AIO 为异步 IO,其他都是同步 IO。

阻塞 IO(blocking IO)

同步阻塞 IO 是最简单、最常见的 IO 模型,在 Linux 中,默认情况下所有的 socket 都是 blocking 的,先看下操作流程。

首先,应用进程发起 IO 系统调用后,应用进程被阻塞,转到内核空间处理。之后,内核开始等待数据,等待到数据之后,再将内核中的数据拷贝到用户内存中,整个 IO 处理完毕后返回进程。最后应用的进程解除阻塞状态,运行业务逻辑。

这里我们可以看到,系统内核处理 IO 操作分为两个阶段——等待数据和拷贝数据。而在这两个阶段中,应用进程中 IO 操作的线程会一直都处于阻塞状态,如果是基于 Java 多线程开发,那么每一个 IO 操作都要占用线程,直至 IO 操作结束。

Read more
PRC核心原理一

什么是 RPC?

我知道你肯定不喜欢听概念,我也是这样,看书的时候一看到概念就直接略过。不过,到后来,我才发现,“定义”是一件多么伟大的事情。当我们能够用一句话把一个东西给定义出来的时候,侧面也说明你已经彻底理解这事了,不仅知道它要解决什么问题,还要知道它的边界。所以,你可以先停下来想想,什么是 RPC。

RPC 的全称是 Remote Procedure Call,即远程过程调用。简单解读字面上的意思,远程肯定是指要跨机器而非本机,所以需要用到网络编程才能实现,但是不是只要通过网络通信访问到另一台机器的应用程序,就可以称之为 RPC 调用了?显然并不够。

我理解的 RPC 是帮助我们屏蔽网络编程细节,实现调用远程方法就跟调用本地(同一个项目中的方法)一样的体验,我们不需要因为这个方法是远程调用就需要编写很多与业务无关的代码。

这就好比建在小河上的桥一样连接着河的两岸,如果没有小桥,我们需要通过划船、绕道等其他方式才能到达对面,但是有了小桥之后,我们就能像在路面上一样行走到达对面,并且跟在路面上行走的体验没有区别。所以我认为,RPC 的作用就是体现在这样两个方面:

  • 屏蔽远程调用跟本地调用的区别,让我们感觉就是调用项目内的方法;
  • 隐藏底层网络通信的复杂性,让我们更专注于业务逻辑。

RPC 通信流程

理解了什么是 RPC,接下来我们讲下 RPC 框架的通信流程,方便我们进一步理解 RPC。

如前面所讲,RPC 能帮助我们的应用透明地完成远程调用,发起调用请求的那一方叫做调用方,被调用的一方叫做服务提供方。为了实现这个的目标,我们就需要在 RPC 框架里面对整个通信细节进行封装,那一个完整的 RPC 会涉及到哪些步骤呢?

Read more
ES最佳实践

集群配置最佳实践

1.磁盘选择

  • 尽可能使用使用 SSD,ES 最大的瓶颈往往是磁盘读写性能,SSD 要比 SATA 查询快 5-10 倍,所以查询要求高的业务建议选择 SSD 或者 PCIE,查询要求不那么高的业务可以选择 SATA
  • 对于数据节点建议使用单机器 500G 以上的磁盘
  • 对于协调节点,200G 足矣,协调节点不存数据,只做转发和聚合

2.内存选择

  • 尽可能选择 16G 以上,由于 ES 的段文件(索引文件)存储在缓存中,尽量满足所有的段文件都存在缓存中,提高查询的效率
  • ES JVM 配置机器一半的内存,但是不要超过 32G
  • 内存和磁盘 1:10

3.集群角色配置

  • 数据节点和协调节点隔离,避免协调节点因数据问题 down 机之后导致整个集群崩溃
  • 集群尽量配置固定数量的协调节点(一般 3 个足矣),数据节点可以扩展

4.分片和副本设置

  • 每个数据节点上都尽量分配某个索引的一个分片,使数据足够均匀
  • 每个索引分片不要超过 30G
  • 单节点数据控制再 2T 以内
Read more
ES搜索原理剖析

一、索引建立

1.1 数据类型

搜索的前提是索引已经建立好,ES 中的数据分为 2 类

  • 精确值:如 id,ip 等,精确值只能精确匹配,适用于 term 查询,查询的时候是根据二进制来比较
  • 全文:指文本内容,比如日志,邮件内容,url 等,适用于 match 查询,只能查出看起来像的结果

以下对五条 doc 建立索引

Name Age Address
Alan 33 West Street Ca USA
Alice 13 East Street La USA
Brad 19 Suzhou JiangSu China
Alice 15 Nanjing JiangSu China
Alan 11 Changning Shanghai China

1.2 索引建立流程

Read more
2020年回顾与感想

一、前言

在想以何种样式来写年度总结,之前2018年的总结以挑出各个维度的几件事来总结,通过此来反思做的好的,做的差的,以及来年目标,这种挺新颖,但目标量化性不够,聚焦性不足。正好最终工作上要进行季度述职,所以打算用比较枯燥但深刻的述职模板来承载2020年总结吧。

二、2020年总结

请重点回顾在本人在周期内的关键策略进展、重要进展、目标达成等。

1、个人目标

上阶段有什么个人目标

阶段性目标 路径
技术能力 1,提升系统架构能力,能够通用性、易用性、扩展性延伸
2,提升技术决策能力,多调研,多总结
表达能力 1,提升自我沟通表达能力
经济知识能力 1,增加自己以经济视角看待问题能力,尝试不同的投资类型

2、目标完成情况及工作成果

上阶段目标完成情况,取得了什么亮点/成果(如有对标情况,请列举),有什么认知迭代

Read more
doris介绍

1.基本概念

1.1Doris(Palo) 简介

Doris 是一个 MPP 的在线 OLAP 系统,主要整合了 Google Mesa (数据模型),Apache Impala (MPP query engine) 和 ORCFile / Parquet (存储格式,编码和压缩) 的技术。

Doris 具有以下特点:

  • 无外部系统依赖
  • 高可靠,高可用,高可扩展
  • 同时支持 高并发点查询和高吞吐的 Ad-hoc 查询
  • 同时支持 批量导入和近实时 mini-batch 导入
  • 兼容 MySQL 协议
  • 支持 Rollup Table 和 Rollup Table 的智能查询路由
  • 支持多表 Join
  • 支持 Schema 在线变更
  • 支持存储分级,旧的冷数据用 SATA,新的热数据用 SSD

Doris 的系统架构如下:

Doris 主要分为 FE 和 BE 两种角色,FE 主要负责查询的编译,分发和元数据管理(基于内存,类似 HDFS NN);BE 主要负责查询的执行和存储系统。

Read more
Flink:什么是 Watermark?

1、什么是 watermark

watermark 网上有翻译成水印,但更应该是水位线,即 Flink 接受的数据就相当于浮在水面的物体, 基于物理知识,水位线的高度只会升高不会降低,那么每当新数据进来,会重新计算水位线的时间,计算结果小于当前水位线时间,则不会更新现有的水位线。 当水位线到达窗口触发时间时才会触发窗口的计算。watermark 的意义在于数据无序传递的时候有一定容错率,如果晚来的数据在容错范围之内,会当做正常传递来处理。

乍一看还是懵逼,那么就看下面的分析。

2、什么是流处理

Flink 被称为真正的流式实时计算框架,其批处理中是流处理的特殊情况。而所谓的流处理,本质特点是在处理数据时,接受一条处理一条。而批处理则是累积数据到一定程度在处理。这是他们本质的区别。

假如我们自己写一个流式框架。我们该如何处理消息。如下,我们看到消息按照顺序一个个发送,接受后按照顺序处理,这是没有什么问题的。

如果消息不按照顺序发送,产生了乱序,这时候该怎么处理?

其实水位线 Watermark 就是其中的解决方案之一。

Read more
推荐系统技术演进趋势:从召回到排序再到重排

推荐系统技术,总体而言,与NLP和图像领域比,发展速度不算太快。不过最近两年,由于深度学习等一些新技术的引入,总体还是表现出了一些比较明显的技术发展趋势。这篇文章试图从推荐系统几个环节,以及不同的技术角度,来对目前推荐技术的比较彰显的技术趋势做个归纳。个人判断较多,偏颇难免,所以还请谨慎参考。

在写技术趋势前,照例还是对推荐系统的宏观架构做个简单说明,以免读者迷失在技术细节中。

实际的工业推荐系统,如果粗分的化,经常讲的有两个阶段。首先是召回,主要根据用户部分特征,从海量的物品库里,快速找回一小部分用户潜在感兴趣的物品,然后交给排序环节,排序环节可以融入较多特征,使用复杂模型,来精准地做个性化推荐。召回强调快,排序强调准。当然,这是传统角度看推荐这个事情。

但是,如果我们更细致地看实用的推荐系统,一般会有四个环节,如下图所示:

四个环节分别是:召回、粗排、精排和重排。召回目的如上所述;有时候因为每个用户召回环节返回的物品数量还是太多,怕排序环节速度跟不上,所以可以在召回和精排之间加入一个粗排环节,通过少量用户和物品特征,简单模型,来对召回的结果进行个粗略的排序,在保证一定精准的前提下,进一步减少往后传送的物品数量,粗排往往是可选的,可用可不同,跟场景有关。之后,是精排环节,使用你能想到的任何特征,可以上你能承受速度极限的复杂模型,尽量精准地对物品进行个性化排序。排序完成后,传给重排环节,传统地看,这里往往会上各种技术及业务策略,比如去已读、去重、打散、多样性保证、固定类型物品插入等等,主要是技术产品策略主导或者为了改进用户体验的。

那么,每个环节,从技术发展的角度看,都各自有怎样的发展趋势呢?下面我们分头说明。

Read more