金富翁

金富翁 查看完整档案

北京编辑武汉理工大学  |  软件工程 编辑微训网  |  前端开发工程师 编辑 jinye111.github.io 编辑
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 个人简介什么都没有

个人动态

金富翁 收藏了文章 · 2月20日

最新阿里Java技术面试题,看这一文就够了!

金三银四跳槽季即将到来,作为 Java 开发者你开始刷面试题了吗?别急,小编整理了阿里技术面试题,看这一文就够了!

clipboard.png

阿里面试题目目录

1:技术一面(基础面试题目)
2:技术二面(技术深度、技术原理)
3:项目实战(项目模拟面试)
4:JAVA开发技术常问的问题
5:阿里必会知识
6:阿里面试范畴
7:面试总结
8:文章福利(答案获取)

一:阿里技术一面(基础掌握牢固)

常用的异常类型?

  • session
  • java锁
  • gc原理
  • hashmap
  • listlink arraylist 区别
  • aop 原理
  • 多线程
  • kafka 原理和容错
  • spark hadoop 原理
  • redis 同步机制
  • classLoader 机制
  • Http 协议
  • cookie的限制
  • 如何设计一个分步式登录系统?
  • Spring加载过程?
  • 自己有没有写过类似Spring这样的AOP事务?
  • spring的加载过程?
  • atomic 与 volatile的区别?
  • Thread的 notify()给notifyAll()的区别?
  • notifiy()是唤醒的那一个线程?
  • Thread.sleep()唤醒以后是否需要重新竞争?
  • 单例有多少种写法? 有什么区别? 你常用哪一种单例,为什么用这种?
  • 问一个Thread.join()相关的问题?
  • 写一个JAVA死锁的列子?
  • 如何解决死锁?
  • GC回收算法,及实现原理?
  • HashMap数据存储结构? key重复了怎么办? 是如何解决的?
  • Spring AOP的实现原理,底层用什么实现的?

阿里技术二面(技术原理、个人擅长的项目)

重点是面试技术原理,以及对技术的热情和专研程度:

  • Java的高级知识
  • 开源框架的原理
  • JVM
  • 多线程
  • 高并发
  • 中间件
  • 之前项目经历,运用的技术,遇到的问题,如何解决,个人有什么收获和成长;
  • 对于技术的热情(平时是否看些技术书籍,逛论坛,写博客,写源代码或程序等)

JAVA开发技术面试可能问到的问题?

我们主要考核的是网络nio 分布式数据库高并发大数据

  • 自定义表格的实现?
  • 动态表单设计?
  • in-jvm(必考)以及jmm缓存模型如何调优?
  • 常用的RPC框架
  • nio和io
  • 并发编程,设计模式
  • 地图组件?
  • hashmap有什么漏洞会导致他变慢?
  • 如何给hashmap的key对象设计他的hashcode?
  • 泛型通配符?在什么情况下使用?
  • 后端方面:redis?分布式框架dubbo(阿里巴巴开源框架)?设计模式?
  • 场景式的问题:秒杀,能列出常见的排队、验证码、库存扣减方式对系统高并发的影响?
  • 能根据实际的需要构建缓存结构提高提高网站的访问速度,熟练使用ehcache、oscache,了解memcache。
  • 了解基于dns轮询的负载均衡,熟练配置web服务器实现负载均衡,程序级能综合使用基于hash或取模等手段实现软负载。
  • 熟悉分布式数据库设计和优化技术,熟练使用mysql、oracle、SqlServer等主流数据库,熟悉hadoop hbase mangodb redis ehcache、oscache

memcache。对于大数据量的数据库处理采用分表分库、数据库读写分离、建立缓存等手段优化性能。

  • 熟练掌握lucene,能基于lucene开发大型的搜索引擎,并能用lucene来改善和优化数据库的like查询。

项目部分

  • 缓存的使用,如果现在需要实现一个简单的缓存,供搜索框中的ajax异步请求调用,使用什么结构?
  • 内存中的缓存不能一直存在,用什么算法定期将搜索权重较低的entry去掉?
  • TCP如何保证安全性
  • 红黑树的问题,B+数
  • JDK1.8中对HashMap的增强,如果一个桶上的节点数量过多,链表+数组的结构就会转换为红黑树。
  • 项目中使用的单机服务器,如果将它部署成分布式服务器?
  • MySQL的常见优化方式、定为慢查询
  • 手写一个线程安全的单例模式

进阿里必会知识:

  • 算法和数据结构数组、链表、二叉树、队列、栈的各种操作(性能,场景)
  • 二分查找和各种变种的二分查找
  • 各类排序算法以及复杂度分析(快排、归并、堆)
  • 各类算法题(手写)
  • 理解并可以分析时间和空间复杂度。
  • 动态规划(笔试回回有。。)、贪心。
  • 红黑树、AVL树、Hash树、Tire树、B树、B+树。
  • 图算法(比较少,也就两个最短路径算法理解吧)
  • 计算机网络OSI7层模型(TCP4层)每层的协议
  • get/post 以及幂等性
  • http 协议头相关
  • 网络攻击(CSRF、XSS)
  • TCP/IP三次握手、四次挥手
  • TCP与UDP比较
  • DDos攻击
  • (B)IO/NIO/AIO三者原理,各个语言是怎么实现的
  • Netty
  • Linux内核select poll epoll
  • 数据库(最多的还是mysql,Nosql有redis)索引(包括分类及优化方式,失效条件,底层结构)
  • sql语法(join,union,子查询,having,group by)
  • 引擎对比(InnoDB,MyISAM)
  • 数据库的锁(行锁,表锁,页级锁,意向锁,读锁,写锁,悲观锁,乐观锁,以及加锁的select sql方式)
  • 隔离级别,依次解决的问题(脏读、不可重复读、幻读)
  • 事务的ACID
  • B树、B+树
  • 优化(explain,慢查询,show profile)
  • 数据库的范式
  • 分库分表,主从复制,读写分离。
  • Nosql相关(redis和memcached区别之类的,如果你熟悉redis,redis还有一堆要问的)
  • 操作系统:进程通信IPC(几种方式),与线程区别
  • OS的几种策略(页面置换,进程调度等,每个里面有几种算法)
  • 互斥与死锁相关的
  • linux常用命令(问的时候都会给具体某一个场景)
  • Linux内核相关(select、poll、epoll)
  • 编程语言(这里只说Java):把我之后的面经过一遍,Java感觉覆盖的就差不多了,不过下面还是分个类。
  • Java基础(面向对象、四个特性、重载重写、static和final等等很多东西)
  • 集合(HashMap、ConcurrentHashMap、各种List,最好结合源码看)
  • 并发和多线程(线程池、SYNC和Lock锁机制、线程通信、volatile、ThreadLocal、CyclicBarrier、Atom包、CountDownLatch、AQS、CAS原理等等)
  • JVM(内存模型、GC垃圾回收,包括分代,GC算法,收集器、类加载和双亲委派、JVM调优,内存泄漏和内存溢出)
  • IO/NIO相关
  • 反射和代理、异常、Java8相关、序列化
  • 设计模式(常用的,jdk中有的)
  • Web相关(servlet、cookie/session、Spring)

阿里面试题目范畴:

  • 内存模型
  • 类加载机制
  • GC
  • JVM调优
  • 线程池原理
  • 动态代理
  • 悲观锁乐观锁
  • 高并发问题
  • 事务隔离级别
  • 索引原理
  • 限流
  • 分库分表
  • 分布式事务提交
  • 微服务
  • dubbo原理

面试总结

公司一般都比较喜欢的人才特点:对技术有热情,强硬的技术基础实力;主动,善于团队协作,善于总结思考。

技术基础以及的问题多看看书准备,不懂的直接说不懂没关系的;在项目细节上多把关一下,根据项目有针对性的谈自己的技术亮点,能表达清楚,可以引导面试官来问你比较擅长的技术问题。

clipboard.png

【文章福利】

现在是跳槽招聘季,为了解决小伙伴们的燃眉之急

小编也准备了一些以上JAVA程序员面试题,小伙伴可以试试。

需要的可以加小编QQ群:552391552,获取!(内附答案详解)

大家如果需要以上面试答案的话点击看一下这篇文章:阿里面试题答案全集

查看原文

金富翁 收藏了文章 · 2月20日

😀一个原生js弹幕

BulletJs

😀一个原生js弹幕库,基于CSS3 Animation

2020-08-13更新

  • 采用rollup打包并发布到npm,rollup打包教程
  • 去除靠IntersectionObserver来对弹道进行调度,采用新的弹道选择算法,增加防重叠检测
  • 支持同速/不同速弹幕
  • 默认情况下直接丢弃排不上对的弹幕,不对其进行缓存,对于必定要上墙的弹幕在push时可以增加一个参数 this.screen.push(danmu, {}, true)(适用于用户自己发的弹幕)
  • 变更名字,想想用拼音起名还是太low了😂😂😂

使用方式

  1. 直接cdn引入

    // 示例代码: https://github.com/hugeorange/BulletJs/blob/master/src/index.html
        <script data-original="https://unpkg.com/js-bullets@0.0.1/dist/BulletJs.min.js"></script>
        <script>
        const screen = new BulletJs('.screen', { 
                          trackHeight: 35 
                        });
        </script>
  2. ESModule 引入

    yarn install js-bullets
    
    // react
    import BulletJs from "js-bullets";
    
    componentDidMount() {
        this.screen = new BulletJs("#danmu-screen", {})
    
        setInterval(() => {
            this.screen.push('<span>12222222</span>')
        }, 1000)
    }
  3. 简单粗暴的办法直接拷贝comps目录下的代码到你的项目中使用,vue、react项目均可

项目产生原因:

  • 因为rc-bullets 是基于 React,可能很多使用其他框架的同学没法使用
  • 新增了 speed 参数,让所有弹幕以相同速度运动(自己项目的需要)
  • animationEnd的时候增加了轨道置空处理
  • queues 队列的处理方式不同
  • 弹幕格式 dom 字符串
  • 去掉了一些自己项目用不到的 api

API

option

选项含义值类型默认值备注
trackHeight轨道高度string50px均分轨道的高度
onStart自定义动画开始函数functionnull开始开始回调
onEnd自定义动画结束函数functionnull弹幕运动结束回调
pauseOnClick鼠标点击暂停booleanfalse再次点击继续
pauseOnHover鼠标悬停暂停booleantrue鼠标进入暂停,离开继续
duration滚动时长string10s传入speed该参数无效
speed滚动速度number100100px/snull
  • 暂停弹幕:screen.pause([<bulletId>]),无参则暂停全部
  • 弹幕继续:screen.resume([<bulletId>]),无参则继续全部

注意事项

  • 弹幕原理:利用 css3 animation 关键帧动画, 从左移动到右,duration 控制速度

    @keyframe name {
        from { transform: translateX(width px) }
        to { transform: translateX(-100%) }
    }
  • 弹幕防重叠原理
  • 原理图screen.pngimage.png
  • 另外一点需要注意的:我在项目里从接口里读出来数据每页20条,每隔 1s 去发一条弹幕(用 setTimeout),这时有个问题,当页面休眠休眠时,会出现setTimeout堆积的情况,解决办法:用 requestAnimationFrame替代 setTimeout
查看原文

金富翁 收藏了文章 · 2月20日

知乎视频播放器开源了~

知乎视频播放器 Griffith 开源介绍

Griffith 是什么?

Griffith 是一个基于 React 的视频播放器,目前已在知乎 web 和 mobile web 内使用,并在 GitHub 上开源。

开源地址及示例

GitHub 地址:https://github.com/zhihu/grif...

CodeSandbox 示例:https://codesandbox.io/s/74ol...

特性

简洁易用的 UI

Griffith 提供了简洁易用的播放器 UI。目前知乎网页端视频播放器就是使用的 Griffith。

Griffith

快捷键支持

Griffith 参考 YouTube 进行了快捷键支持,后续还会添加更多的快捷键。

  • 空格键:进度条处于选中状态时,可控制视频的播放/暂停。如果已经选中某个按钮,则可用于点击该按钮。
  • K: 在播放器中暂停/播放视频。
  • 选中进度条状态下的向左/向右箭头:快进/快退 5 秒钟。
  • J:在播放器中快退 10 秒。
  • L:在播放器中快进 10 秒。
  • 选中进度条状态下的向上/向下箭头:将音量增大/减小 5%。
  • 选中进度条状态下的数字 1 到 9(不是数字小键盘上的数字):跳至视频进度的 10% 到 90%。
  • 选中进度条状态下的数字 0(不是数字小键盘上的 0):跳至视频的开头。
  • F:启用全屏模式。如果已启用全屏模式,则再次按 F 键或按 Esc 键可退出全屏模式。
  • M:切换静音。

React-friendly

Griffith 是一个基于 React 开发的 web 视频播放器。对于 React 应用,可以直接通过组件调用的方式使用。

Griffith 使用 Context API 进行状态管理。对于 React 应用,可以通过引入 Griffith 的 Context 来实现弹幕等自定义功能。

免构建

对于非 React 应用,或者不愿意通过 npm 包安装的用户,Griffith 提供 standalone 模式可以免构建工具直接在浏览器中使用。

丰富的事件系统

Griffith 定义了丰富的事件系统。

对于视频播放器中常见的首帧时长,缓冲次数等指标,可以通过接收 Griffith 事件来进行打点记录。

对于一些需要与播放器进行通信的功能,可以通过往 Griffith 发送事件来与播放器进行交互。

流式播放

Griffith 使用了 Media Source Extensions™ ,支持对 mp4 和 m3u8 格式的视频进行流式播放。

  • 预加载策略: Griffith 可以通过 MSE 动态控制视频加载进度,以达到节省视频 CDN 带宽等目地。
  • 动态平滑切换清晰度:Griffith 可以通过 MSE 实现动态平滑切换视频清晰度。

如何使用

React 应用

import Player from 'griffith'

const sources = {
  hd: {
    play_url: 'https://zhstatic.zhihu.com/cfe/griffith/zhihu2018hd.mp4',
  },
  sd: {
    play_url: 'https://zhstatic.zhihu.com/cfe/griffith/zhihu2018sd.mp4',
  },
}

render(<Player sources={sources} />)

standalone 模式

<div id="player"></div>
<script data-original="https://unpkg.com/griffith-standalone/dist/index.umd.min.js"></script>
<script>
  const target = document.getElementById('player')

  const sources = {
    hd: {
      play_url: 'https://zhstatic.zhihu.com/cfe/griffith/zhihu2018hd.mp4',
    } ,
    sd: {
      play_url: 'https://zhstatic.zhihu.com/cfe/griffith/zhihu2018sd.mp4',
    },
  }

  // 创建播放器
  const player = Griffith.createPlayer(target)

  // 载入视频
  player.render({sources})

  // 销毁视频
  player.dispose()
</script>

技术细节

  • 使用 Yarn workspace 和 Lerna 进行多包管理。
  • 使用 rollup 和 webpack 进行打包。
  • 使用 new Context API 进行状态管理。
  • 使用 CSS-in-JS 方案来管理样式。
  • 使用 Jest 来进行单元测试编写。
  • 使用 Prettier 进行代码格式统一。
  • 使用 hlsjs 来实现流式播放 m3u8 格式视频。
  • 使用 griffith-mp4 进行 mp4 到 fmp4 格式的转换并通过 MSE 实现流式播放。

结语

Griffith 所有的工作都会在 GitHub 上进行(知乎内部使用的也是同一个仓库)。如果有任何相关的疑问和 bug,欢迎在 GitHub 提交 issue、PR 帮助 Griffith 变得更好。

查看原文

金富翁 收藏了文章 · 2月20日

使用 mask 实现视频弹幕人物遮罩过滤

经常看一些 LOL 比赛直播的小伙伴,肯定都知道,在一些弹幕网站(Bilibili、虎牙)中,当人物与弹幕出现在一起的时候,弹幕会“巧妙”的躲到人物的下面,看着非常的智能。

简单的一个截图例子:

image

其实,这里是运用了 CSS 中的 MASK 属性实现的。

mask 简单用法介绍

之前在多篇文章都提到了 mask,比较详细的一篇是 -- 奇妙的 CSS MASK,本文不对 mask 的基本概念做过多讲解,向下阅读时,如果对一些 mask 的用法感到疑惑,可以再去看看。

这里只简单介绍下 mask 的基本用法:

最基本,使用 mask 的方式是借助图片,类似这样:

{
    /* Image values */
    mask: url(mask.png);                       /* 使用位图来做遮罩 */
    mask: url(masks.svg#star);                 /* 使用 SVG 图形中的形状来做遮罩 */
}

当然,使用图片的方式后文会再讲。借助图片的方式其实比较繁琐,因为我们首先还得准备相应的图片素材,除了图片,mask 还可以接受一个类似 background 的参数,也就是渐变。

类似如下使用方法:

{
    mask: linear-gradient(#000, transparent)                      /* 使用渐变来做遮罩 */
}

那该具体怎么使用呢?一个非常简单的例子,上述我们创造了一个从黑色到透明渐变色,我们将它运用到实际中,代码类似这样:

下面这样一张图片,叠加上一个从透明到黑色的渐变,

{
    background: url(image.png) ;
    mask: linear-gradient(90deg, transparent, #fff);
}

image

应用了 mask 之后,就会变成这样:

image

这个 DEMO,可以先简单了解到 mask 的基本用法。

这里得到了使用 mask 最重要结论:添加了 mask 属性的元素,其内容会与 mask 表示的渐变的 transparent 的重叠部分,并且重叠部分将会变得透明。

值得注意的是,上面的渐变使用的是 linear-gradient(90deg, transparent, #fff),这里的 #fff 纯色部分其实换成任意颜色都可以,不影响效果。

CodePen Demo -- 使用 MASK 的基本使用

使用 mask 实现人物遮罩过滤

了解了 mask 的用法后,接下来,我们运用 mask,简单实现视频弹幕中,弹幕碰到人物,自动被隐藏过滤的例子。

首先,我简单的模拟了一个召唤师峡谷,以及一些基本的弹幕:

mask1

方便示意,这里使用了一张静态图,表示了召唤师峡谷的地图,并非真的视频,而弹幕则是一条一条的 <p> 元素,和实际情况一致。伪代码大概是这样:

<!-- 地图 -->
<div class="g-map"></div>
<!-- 包裹所有弹幕的容器 -->
<div class="g-barrage-container">
    <!-- 所有弹幕 -->
    <div class="g-barrage">6666</div>
    ...
    <div class="g-barrage">6666</div>
</div>

为了模拟实际情况,我们再用一个 div 添加一个实际的人物,如果不做任何处理,其实就是我们看视频打开弹幕的感受,人物被视频所遮挡:

mask2

注意,这里我添加了一个人物亚索,并且用 animation 模拟了简单的运动,在运动的过程中,人物是被弹幕给遮挡住的。

接下来,就可以请出 mask 了。

我们利用 mask 制作一个 radial-gradient ,使得人物附近为 transparent,并且根据人物运动的 animation,给 mask 的 mask-position 也添加上相同的 animation 即可。最终可以得到这样的效果:

.g-barrage-container {
    position: absolute;
    mask: radial-gradient(circle at 100px 100px, transparent 60px, #fff 80px, #fff 100%);
    animation: mask 10s infinite alternate;
}

@keyframes mask {
    100% {
        mask-position: 85vw 0;
    }
}

mask3

实际上就是给放置弹幕的容器,添加一个 mask 属性,把人物所在的位置标识出来,并且根据人物的运动不断的去变换这个 mask 即可。我们把 mask 换成 background,原理一看就懂。

  • 把 mask 替换成 background 示意图:

mask4

background 透明的地方,即 mask 中为 transparent 的部分,实际就是弹幕会被隐藏遮罩的部分,而其他白色部分,弹幕不会被隐藏,正是完美的利用了 mask 的特性。

其实这项技术和视频本身是无关的,我们只需要根据视频计算需要屏蔽掉弹幕的位置,得到相应的 mask 参数即可。如果去掉背景和运动的人物,只保留弹幕和 mask,是这样的:

mask6

需要明确的是,使用 mask,不是将弹幕部分给遮挡住,而是利用 mask,指定弹幕容器之下,哪些部分正常展示,哪些部分透明隐藏

最后,完整的 Demo 你可以戳这里:

CodePen Demo -- mask 实现弹幕人物遮罩过滤

实际生产环境中的运用

当然,上面我们简单的还原了利用 mask 实现弹幕遮罩过滤的效果。但是实际情况比上述的场景复杂的多,因为人物英雄的位置是不确定的,每一刻都在变化。所以在实际生产环境中,mask 图片的参数,其实是由后端实时对视频进行处理计算出来的,然后传给前端,前端再进行渲染。

对于运用了这项技术的直播网站,我们可以审查元素,看到包裹弹幕的容器的 mask 属性,每时每刻都在发生变化:

mask5

返回回来的其实是一个 SVG 图片,大概长这个样子:

image

这样,根据视频人物的实时位置变化,不断计算新的 mask,再实时作用于弹幕容器之上,实现遮罩过滤。

最后

本文到此结束,希望对你有帮助 :),本文介绍了 CSS mask 的一个实际生产环境中,非常有意义的一次实践,也表明很多新的 CSS 技术,运用得当,还是能给业务带来非常有益的帮助的。

想 Get 到最有意思的 CSS 资讯,千万不要错过我的公众号 -- iCSS前端趣闻 😄

gzh_small.png

更多精彩 CSS 技术文章汇总在我的 Github -- iCSS ,持续更新,欢迎点个 star 订阅收藏。

如果还有什么疑问或者建议,可以多多交流,原创文章,文笔有限,才疏学浅,文中若有不正之处,万望告知。

查看原文

金富翁 关注了用户 · 2月20日

芒果果 @wangying_5ea4fb9de961c

一路走走看看,顺便留下点什么。

关注 51

金富翁 收藏了文章 · 2月20日

火星无人机全部代码公开!毅力号带着手机芯片和 Linux 系统上太空

毅力号登陆火星,带着手机芯片和 Linux 系统上太空了!

历经 203 天,穿越了 4.72 亿公里之后,美国“毅力号”火星车终于在美东时间下午 3:55 成功登陆火星。

结束近 7 个月的旅程后,“毅力号”传回了通过避险摄像机拍摄的第一张火星表面景象。这次,“毅力号”的主要任务是——寻找古代生命的迹象,并收集火星岩石和土壤样本带回地球研究。

值得一提的是,配合“毅力号”完成探测任务的“机智号”无人机搭载的是骁龙 801 处理器。没错,就是那个用在手机上的骁龙 801。当年,小米 4 用的就是这款芯片。

此外,这也是人类第一次在火星上运行 Linux 系统。“毅力号”上的无人机“机智号”实际上是通过 Linux 操作系统控制的。不止如此,NASA 还把这个专门为火星无人机开发的 Linux 飞行控制系统开源了!

这就是毅力号在火星表面拍摄的第一张图像:

image.png

“恐怖 7 分钟”艰难着陆

2020 年 7 月 30 日,耗资 24 亿美元的毅力号从美国佛罗里达州的卡纳维拉尔角太空部队站发射升空,带着收集火星样本的任务迈出了火星探索的第一步。

美国宇航局科学副主任托马斯说,“毅力号是从火星带回岩石的第一步,我们不知道这些来自火星的原始样本会告诉我们什么,但无疑是非常重要的,甚至可能包括曾经存在于地球之外的生命。”

image.png

毅力号进入下降阶段时,以大约 20000 km/h 的速度飞行,尽管火星的气氛很稀薄,但它仍将给毅力号带来极大的阻力。进入火星大气层大约 80 秒钟之内,航空器外壳外部的温度将达到 1300 摄氏度。

约四分钟后,毅力号的“降落伞”展开,保护性航空器外壳脱落。当毅力号下降到火星表面上方约 4 公里时,它将激活其地形导航系统。

410 秒后(将近 7 分钟),毅力号终于在火星成功着陆。与 2018 年 8 月的“好奇号”火星车非常相似,它也在着陆时经历了类似的“恐怖 7 分钟”。

image.png

火星表面首次有直升机起飞

毅力号首次将直升机带上了火星,机智号火星无人机将在火星表面飞起几英尺的高度,并在毅力号火星车的周围盘旋,收集图像信息。这将是直升机在火星极薄的大气层中首次实现动力飞行。

image.png

机智号无人机仅重 1.8 公斤,通过顶部安装的 4 个碳纤维螺旋桨提供动力,每分钟转速为 2400 转,功率为 350 瓦。为了配合毅力号的探测任务,它要面对许多挑战。

要知道,实现直升机在火星上飞行是有很大难度的。一方面火星的稀薄大气使得难以获得足够的升力。另一方面由于火星大气层的密度比地球密度低 99%,直升机的旋转叶片也要做的更大,并且转速要非常快才能起飞。

image.png

机智号采用骁龙 801 处理器,带着 Linux 系统上火星

由于太空探索对硬件设备的稳定性要求极高,很多设备都采用了已经在地面运行了多年的处理器,机智号也是如此。但值得注意的是,机智号这次没有采用商业级别的处理器,而是用于手机的民用处理器。这是因为,机智号被 NASA 视为一项“技术演示”,因此愿意接受更多风险,于是采用了民用的骁龙 801 处理器。

image.png

此外,由于毅力号的任务对信息的收集和处理要求极高,需要捕捉图像、分析特征,并以 30 赫兹的频率从一帧到另一帧跟踪它们。以往已经使用多年的商业级处理器已无法达到标准。而骁龙 801 的本质是一款手机处理器,而且它的主板非常小。它的功能远比其他火星车上的处理器多得多,拥有更强大的计算力。

除了手机处理器,机智号还带来了一个惊喜,将 Linux 带上了火星。

这是人类第一次在火星上使用 Linux 飞行控制系统,据 NASA 介绍,机智号使用的软件框架是JPL 为立方体卫星和仪器开发的,并在几年前就开源了。也就是说,任何人都能使用这个在火星直升机上的软件框架,并将它用在你自己的项目上。

将开源进行到底,火星无人机代码已全部公开

F Prime 是火星无人机“机智号”的飞行软件框架,目前已在 GitHub 上全部公开!

F Prime 是为机智号量身定制的一个组件驱动的框架,可以快速开发和部署太空飞行及其他嵌入式软件应用程序。

那么,有了这些公开的代码,我们是不是也能下载机智号同款代码搞个火星无人机出来了呢?

image.png

NASA 开源的 F Prime 提供了一个完整的开发生态系统,包括建模工具、测试工具和地面数据系统。开发人员使用建模工具编写高级规范,自动使用 C ++ 生成实现,并使用特定领域的代码填充实现。框架和代码生成器提供 F Prime 部署所需的所有样板代码,包括用于线程管理的代码,用于组件之间通信的代码以及用于处理命令,遥测和参数的代码。测试工具和地面数据系统简化了在工作站和实验室中的飞行硬件上的软件测试。

此外,F Prime 还实现了以下几个关键功能:

1.可重用性:基于组件的体系结构可实现高度的模块化和软件重用。

2.可移植性:F Prime 在从微控制器到多核计算机的多种处理器以及多种操作系统上运行,将其移植到新的操作系统非常简单。

3.高性能:采用点对点架构,最大程度地减少了计算资源的使用,非常适合较小的处理器。

4.量身定制,可满足小型任务所需的复杂程度,不仅易于使用,还能同时仍支持多种任务。

5.可分析性:类型化的端口连接为编译时的正确性提供了有力的保证。

快速安装指南

前提条件:

  • cmake
  • git
  • Python 3.5+ with pip

安装这些实用程序后,即可安装 F Prime Python 依赖项。在 Python 虚拟环境中安装依赖项可以防止系统级问题,但是不需要在虚拟环境中进行安装。

要快速安装 F Prime,请输入:

image.png

太空冒险迈上新台阶,“移民火星”不是梦

毅力号将在火星完成一系列高度复杂的任务,为人类探索古代生物信息和火星土壤研究提供有力支持。随着毅力号一起登陆火星的机智号也为人类的太空事业迈上了一个更高的台阶。

与此同时,中国的“天问一号”火星车也即将今年 5 月登陆火星。人类的太空冒险仍在继续,也许“移民火星”在未来的某一天真的将不止是梦想,而真正照进现实。

参考链接:https://spectrum.ieee.org/aut...
https://www.futurezone.de/sci...
GitHub 地址:https://github.com/nasa/fprime

segmentfault 公众号

查看原文

金富翁 关注了用户 · 2月20日

panjf2000 @panjf2000

程序猿。

关注 45

金富翁 关注了专栏 · 2月20日

编程札记

分享一点技术心得与经验,包括但不限于:编程语言的深入理解、系统架构与设计、分布式、云原生等。

关注 2461

金富翁 收藏了文章 · 2月20日

Redis 多线程网络模型全面揭秘

博客原文

Redis 多线程网络模型全面揭秘

导言

在目前的技术选型中,Redis 俨然已经成为了系统高性能缓存方案的事实标准,因此现在 Redis 也成为了后端开发的基本技能树之一,Redis 的底层原理也顺理成章地成为了必须学习的知识。

Redis 从本质上来讲是一个网络服务器,而对于一个网络服务器来说,网络模型是它的精华,搞懂了一个网络服务器的网络模型,你也就搞懂了它的本质。

本文通过层层递进的方式,介绍了 Redis 网络模型的版本变更历程,剖析了其从单线程进化到多线程的工作原理,此外,还一并分析并解答了 Redis 的网络模型的很多抉择背后的思考,帮助读者能更深刻地理解 Redis 网络模型的设计。

Redis 有多快?

根据官方的 benchmark,通常来说,在一台普通硬件配置的 Linux 机器上跑单个 Redis 实例,处理简单命令(时间复杂度 O(N) 或者 O(log(N))),QPS 可以达到 8w+,而如果使用 pipeline 批处理功能,则 QPS 至高能达到 100w。

仅从性能层面进行评判,Redis 完全可以被称之为高性能缓存方案。

Redis 为什么快?

Redis 的高性能得益于以下几个基础:

  • C 语言实现,虽然 C 对 Redis 的性能有助力,但语言并不是最核心因素。
  • 纯内存 I/O,相较于其他基于磁盘的 DB,Redis 的纯内存操作有着天然的性能优势。
  • I/O 多路复用,基于 epoll/select/kqueue 等 I/O 多路复用技术,实现高吞吐的网络 I/O。
  • 单线程模型,单线程无法利用多核,但是从另一个层面来说则避免了多线程频繁上下文切换,以及同步机制如锁带来的开销。

Redis 为何选择单线程?

Redis 的核心网络模型选择用单线程来实现,这在一开始就引起了很多人的不解,Redis 官方的对于此的回答是:

It's not very frequent that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound. For instance, using pipelining Redis running on an average Linux system can deliver even 1 million requests per second, so if your application mainly uses O(N) or O(log(N)) commands, it is hardly going to use too much CPU.

核心意思就是,对于一个 DB 来说,CPU 通常不会是瓶颈,因为大多数请求不会是 CPU 密集型的,而是 I/O 密集型。具体到 Redis 的话,如果不考虑 RDB/AOF 等持久化方案,Redis 是完全的纯内存操作,执行速度是非常快的,因此这部分操作通常不会是性能瓶颈,Redis 真正的性能瓶颈在于网络 I/O,也就是客户端和服务端之间的网络传输延迟,因此 Redis 选择了单线程的 I/O 多路复用来实现它的核心网络模型。

上面是比较笼统的官方答案,实际上更加具体的选择单线程的原因可以归纳如下:

避免过多的上下文切换开销

多线程调度过程中必然需要在 CPU 之间切换线程上下文 context,而上下文的切换又涉及程序计数器、堆栈指针和程序状态字等一系列的寄存器置换、程序堆栈重置甚至是 CPU 高速缓存、TLB 快表的汰换,如果是进程内的多线程切换还好一些,因为单一进程内多线程共享进程地址空间,因此线程上下文比之进程上下文要小得多,如果是跨进程调度,则需要切换掉整个进程地址空间。

如果是单线程则可以规避进程内频繁的线程切换开销,因为程序始终运行在进程中单个线程内,没有多线程切换的场景。

避免同步机制的开销

如果 Redis 选择多线程模型,又因为 Redis 是一个数据库,那么势必涉及到底层数据同步的问题,则必然会引入某些同步机制,比如锁,而我们知道 Redis 不仅仅提供了简单的 key-value 数据结构,还有 list、set 和 hash 等等其他丰富的数据结构,而不同的数据结构对同步访问的加锁粒度又不尽相同,可能会导致在操作数据过程中带来很多加锁解锁的开销,增加程序复杂度的同时还会降低性能。

简单可维护

Redis 的作者 Salvatore Sanfilippo (别称 antirez) 对 Redis 的设计和代码有着近乎偏执的简洁性理念,你可以在阅读 Redis 的源码或者给 Redis 提交 PR 的之时感受到这份偏执。因此代码的简单可维护性必然是 Redis 早期的核心准则之一,而引入多线程必然会导致代码的复杂度上升和可维护性下降。

事实上,多线程编程也不是那么尽善尽美,首先多线程的引入会使得程序不再保持代码逻辑上的串行性,代码执行的顺序将变成不可预测的,稍不注意就会导致程序出现各种并发编程的问题;其次,多线程模式也使得程序调试更加复杂和麻烦。网络上有一幅很有意思的图片,生动形象地描述了并发编程面临的窘境。

你期望的多线程编程 VS 实际上的多线程编程:

你期望的多线程VS实际上的多线程

前面我们提到引入多线程必须的同步机制,如果 Redis 使用多线程模式,那么所有的底层数据结构都必须实现成线程安全的,这无疑又使得 Redis 的实现变得更加复杂。

总而言之,Redis 选择单线程可以说是多方博弈之后的一种权衡:在保证足够的性能表现之下,使用单线程保持代码的简单和可维护性。

Redis 真的是单线程?

在讨论这个问题之前,我们要先明确『单线程』这个概念的边界:它的覆盖范围是核心网络模型,抑或是整个 Redis?如果是前者,那么答案是肯定的,在 Redis 的 v6.0 版本正式引入多线程之前,其网络模型一直是单线程模式的;如果是后者,那么答案则是否定的,Redis 早在 v4.0 就已经引入了多线程。

因此,当我们讨论 Redis 的多线程之时,有必要对 Redis 的版本划出两个重要的节点:

  1. Redis v4.0(引入多线程处理异步任务)
  2. Redis v6.0(正式在网络模型中实现 I/O 多线程)

单线程事件循环

我们首先来剖析一下 Redis 的核心网络模型,从 Redis 的 v1.0 到 v6.0 版本之前,Redis 的核心网络模型一直是一个典型的单 Reactor 模型:利用 epoll/select/kqueue 等多路复用技术,在单线程的事件循环中不断去处理事件(客户端请求),最后回写响应数据到客户端:

这里有几个核心的概念需要学习:

  • client:客户端对象,Redis 是典型的 CS 架构(Client <---> Server),客户端通过 socket 与服务端建立网络通道然后发送请求命令,服务端执行请求的命令并回复。Redis 使用结构体 client 存储客户端的所有相关信息,包括但不限于封装的套接字连接 -- *conn当前选择的数据库指针 -- *db读入缓冲区 -- querybuf写出缓冲区 -- buf写出数据链表 -- reply等。
  • aeApiPoll:I/O 多路复用 API,是基于 epoll_wait/select/kevent 等系统调用的封装,监听等待读写事件触发,然后处理,它是事件循环(Event Loop)中的核心函数,是事件驱动得以运行的基础。
  • acceptTcpHandler:连接应答处理器,底层使用系统调用 accept 接受来自客户端的新连接,并为新连接注册绑定命令读取处理器,以备后续处理新的客户端 TCP 连接;除了这个处理器,还有对应的 acceptUnixHandler 负责处理 Unix Domain Socket 以及 acceptTLSHandler 负责处理 TLS 加密连接。
  • readQueryFromClient:命令读取处理器,解析并执行客户端的请求命令。
  • beforeSleep:事件循环中进入 aeApiPoll 等待事件到来之前会执行的函数,其中包含一些日常的任务,比如把 client->buf 或者 client->reply (后面会解释为什么这里需要两个缓冲区)中的响应写回到客户端,持久化 AOF 缓冲区的数据到磁盘等,相对应的还有一个 afterSleep 函数,在 aeApiPoll 之后执行。
  • sendReplyToClient:命令回复处理器,当一次事件循环之后写出缓冲区中还有数据残留,则这个处理器会被注册绑定到相应的连接上,等连接触发写就绪事件时,它会将写出缓冲区剩余的数据回写到客户端。

Redis 内部实现了一个高性能的事件库 --- AE,基于 epoll/select/kqueue/evport 四种事件驱动技术,实现 Linux/MacOS/FreeBSD/Solaris 多平台的高性能事件循环模型。Redis 的核心网络模型正式构筑在 AE 之上,包括 I/O 多路复用、各类处理器的注册绑定,都是基于此才得以运行。

至此,我们可以描绘出客户端向 Redis 发起请求命令的工作原理:

  1. Redis 服务器启动,开启主线程事件循环(Event Loop),注册 acceptTcpHandler 连接应答处理器到用户配置的监听端口对应的文件描述符,等待新连接到来;
  2. 客户端和服务端建立网络连接;
  3. acceptTcpHandler 被调用,主线程使用 AE 的 API 将 readQueryFromClient 命令读取处理器绑定到新连接对应的文件描述符上,并初始化一个 client 绑定这个客户端连接;
  4. 客户端发送请求命令,触发读就绪事件,主线程调用 readQueryFromClient 通过 socket 读取客户端发送过来的命令存入 client->querybuf 读入缓冲区;
  5. 接着调用 processInputBuffer,在其中使用 processInlineBuffer 或者 processMultibulkBuffer 根据 Redis 协议解析命令,最后调用 processCommand 执行命令;
  6. 根据请求命令的类型(SET, GET, DEL, EXEC 等),分配相应的命令执行器去执行,最后调用 addReply 函数族的一系列函数将响应数据写入到对应 client 的写出缓冲区:client->buf 或者 client->replyclient->buf 是首选的写出缓冲区,固定大小 16KB,一般来说可以缓冲足够多的响应数据,但是如果客户端在时间窗口内需要响应的数据非常大,那么则会自动切换到 client->reply 链表上去,使用链表理论上能够保存无限大的数据(受限于机器的物理内存),最后把 client 添加进一个 LIFO 队列 clients_pending_write
  7. 在事件循环(Event Loop)中,主线程执行 beforeSleep --> handleClientsWithPendingWrites,遍历 clients_pending_write 队列,调用 writeToClientclient 的写出缓冲区里的数据回写到客户端,如果写出缓冲区还有数据遗留,则注册 sendReplyToClient 命令回复处理器到该连接的写就绪事件,等待客户端可写时在事件循环中再继续回写残余的响应数据。

对于那些想利用多核优势提升性能的用户来说,Redis 官方给出的解决方案也非常简单粗暴:在同一个机器上多跑几个 Redis 实例。事实上,为了保证高可用,线上业务一般不太可能会是单机模式,更加常见的是利用 Redis 分布式集群多节点和数据分片负载均衡来提升性能和保证高可用。

多线程异步任务

以上便是 Redis 的核心网络模型,这个单线程网络模型一直到 Redis v6.0 才改造成多线程模式,但这并不意味着整个 Redis 一直都只是单线程。

Redis 在 v4.0 版本的时候就已经引入了的多线程来做一些异步操作,此举主要针对的是那些非常耗时的命令,通过将这些命令的执行进行异步化,避免阻塞单线程的事件循环。

我们知道 Redis 的 DEL 命令是用来删除掉一个或多个 key 储存的值,它是一个阻塞的命令,大多数情况下你要删除的 key 里存的值不会特别多,最多也就几十上百个对象,所以可以很快执行完,但是如果你要删的是一个超大的键值对,里面有几百万个对象,那么这条命令可能会阻塞至少好几秒,又因为事件循环是单线程的,所以会阻塞后面的其他事件,导致吞吐量下降。

Redis 的作者 antirez 为了解决这个问题进行了很多思考,一开始他想的办法是一种渐进式的方案:利用定时器和数据游标,每次只删除一小部分的数据,比如 1000 个对象,最终清除掉所有的数据,但是这种方案有个致命的缺陷,如果同时还有其他客户端往某个正在被渐进式删除的 key 里继续写入数据,而且删除的速度跟不上写入的数据,那么将会无止境地消耗内存,虽然后来通过一个巧妙的办法解决了,但是这种实现使 Redis 变得更加复杂,而多线程看起来似乎是一个水到渠成的解决方案:简单、易理解。于是,最终 antirez 选择引入多线程来实现这一类非阻塞的命令。更多 antirez 在这方面的思考可以阅读一下他发表的博客:Lazy Redis is better Redis

于是,在 Redis v4.0 之后增加了一些的非阻塞命令如 UNLINKFLUSHALL ASYNCFLUSHDB ASYNC

UNLINK 命令其实就是 DEL 的异步版本,它不会同步删除数据,而只是把 key 从 keyspace 中暂时移除掉,然后将任务添加到一个异步队列,最后由后台线程去删除,不过这里需要考虑一种情况是如果用 UNLINK 去删除一个很小的 key,用异步的方式去做反而开销更大,所以它会先计算一个开销的阀值,只有当这个值大于 64 才会使用异步的方式去删除 key,对于基本的数据类型如 List、Set、Hash 这些,阀值就是其中存储的对象数量。

Redis 多线程网络模型

前面提到 Redis 最初选择单线程网络模型的理由是:CPU 通常不会成为性能瓶颈,瓶颈往往是内存网络,因此单线程足够了。那么为什么现在 Redis 又要引入多线程呢?很简单,就是 Redis 的网络 I/O 瓶颈已经越来越明显了。

随着互联网的飞速发展,互联网业务系统所要处理的线上流量越来越大,Redis 的单线程模式会导致系统消耗很多 CPU 时间在网络 I/O 上从而降低吞吐量,要提升 Redis 的性能有两个方向:

  • 优化网络 I/O 模块
  • 提高机器内存读写的速度

后者依赖于硬件的发展,暂时无解。所以只能从前者下手,网络 I/O 的优化又可以分为两个方向:

  • 零拷贝技术或者 DPDK 技术
  • 利用多核优势

零拷贝技术有其局限性,无法完全适配 Redis 这一类复杂的网络 I/O 场景,更多网络 I/O 对 CPU 时间的消耗和 Linux 零拷贝技术,可以阅读我的另一篇文章:Linux I/O 原理和 Zero-copy 技术全面揭秘。而 DPDK 技术通过旁路网卡 I/O 绕过内核协议栈的方式又太过于复杂以及需要内核甚至是硬件的支持。

因此,利用多核优势成为了优化网络 I/O 性价比最高的方案。

6.0 版本之后,Redis 正式在核心网络模型中引入了多线程,也就是所谓的 I/O threading,至此 Redis 真正拥有了多线程模型。前一小节,我们了解了 Redis 在 6.0 版本之前的单线程事件循环模型,实际上就是一个非常经典的 Reactor 模型:

目前 Linux 平台上主流的高性能网络库/框架中,大都采用 Reactor 模式,比如 netty、libevent、libuv、POE(Perl)、Twisted(Python)等。

Reactor 模式本质上指的是使用 I/O 多路复用(I/O multiplexing) + 非阻塞 I/O(non-blocking I/O) 的模式。

更多关于 Reactor 模式的细节可以参考我之前的文章:Go netpoller 原生网络模型之源码全面揭秘,Reactor 网络模型那一小节,这里不再赘述。

Redis 的核心网络模型在 6.0 版本之前,一直是单 Reactor 模式:所有事件的处理都在单个线程内完成,虽然在 4.0 版本中引入了多线程,但是那个更像是针对特定场景(删除超大 key 值等)而打的补丁,并不能被视作核心网络模型的多线程。

通常来说,单 Reactor 模式,引入多线程之后会进化为 Multi-Reactors 模式,基本工作模式如下:

区别于单 Reactor 模式,这种模式不再是单线程的事件循环,而是有多个线程(Sub Reactors)各自维护一个独立的事件循环,由 Main Reactor 负责接收新连接并分发给 Sub Reactors 去独立处理,最后 Sub Reactors 回写响应给客户端。

Multiple Reactors 模式通常也可以等同于 Master-Workers 模式,比如 Nginx 和 Memcached 等就是采用这种多线程模型,虽然不同的项目实现细节略有区别,但总体来说模式是一致的。

设计思路

Redis 虽然也实现了多线程,但是却不是标准的 Multi-Reactors/Master-Workers 模式,这其中的缘由我们后面会分析,现在我们先看一下 Redis 多线程网络模型的总体设计:

  1. Redis 服务器启动,开启主线程事件循环(Event Loop),注册 acceptTcpHandler 连接应答处理器到用户配置的监听端口对应的文件描述符,等待新连接到来;
  2. 客户端和服务端建立网络连接;
  3. acceptTcpHandler 被调用,主线程使用 AE 的 API 将 readQueryFromClient 命令读取处理器绑定到新连接对应的文件描述符上,并初始化一个 client 绑定这个客户端连接;
  4. 客户端发送请求命令,触发读就绪事件,服务端主线程不会通过 socket 去读取客户端的请求命令,而是先将 client 放入一个 LIFO 队列 clients_pending_read
  5. 在事件循环(Event Loop)中,主线程执行 beforeSleep -->handleClientsWithPendingReadsUsingThreads,利用 Round-Robin 轮询负载均衡策略,把 clients_pending_read队列中的连接均匀地分配给 I/O 线程各自的本地 FIFO 任务队列 io_threads_list[id] 和主线程自己,I/O 线程通过 socket 读取客户端的请求命令,存入 client->querybuf 并解析第一个命令,但不执行命令,主线程忙轮询,等待所有 I/O 线程完成读取任务;
  6. 主线程和所有 I/O 线程都完成了读取任务,主线程结束忙轮询,遍历 clients_pending_read 队列,执行所有客户端连接的请求命令,先调用 processCommandAndResetClient 执行第一条已经解析好的命令,然后调用 processInputBuffer 解析并执行客户端连接的所有命令,在其中使用 processInlineBuffer 或者 processMultibulkBuffer 根据 Redis 协议解析命令,最后调用 processCommand 执行命令;
  7. 根据请求命令的类型(SET, GET, DEL, EXEC 等),分配相应的命令执行器去执行,最后调用 addReply 函数族的一系列函数将响应数据写入到对应 client 的写出缓冲区:client->buf 或者 client->replyclient->buf 是首选的写出缓冲区,固定大小 16KB,一般来说可以缓冲足够多的响应数据,但是如果客户端在时间窗口内需要响应的数据非常大,那么则会自动切换到 client->reply 链表上去,使用链表理论上能够保存无限大的数据(受限于机器的物理内存),最后把 client 添加进一个 LIFO 队列 clients_pending_write
  8. 在事件循环(Event Loop)中,主线程执行 beforeSleep --> handleClientsWithPendingWritesUsingThreads,利用 Round-Robin 轮询负载均衡策略,把 clients_pending_write 队列中的连接均匀地分配给 I/O 线程各自的本地 FIFO 任务队列 io_threads_list[id] 和主线程自己,I/O 线程通过调用 writeToClientclient 的写出缓冲区里的数据回写到客户端,主线程忙轮询,等待所有 I/O 线程完成写出任务;
  9. 主线程和所有 I/O 线程都完成了写出任务, 主线程结束忙轮询,遍历 clients_pending_write 队列,如果 client 的写出缓冲区还有数据遗留,则注册 sendReplyToClient 到该连接的写就绪事件,等待客户端可写时在事件循环中再继续回写残余的响应数据。

这里大部分逻辑和之前的单线程模型是一致的,变动的地方仅仅是把读取客户端请求命令和回写响应数据的逻辑异步化了,交给 I/O 线程去完成,这里需要特别注意的一点是:I/O 线程仅仅是读取和解析客户端命令而不会真正去执行命令,客户端命令的执行最终还是要在主线程上完成

源码剖析

以下所有代码基于目前最新的 Redis v6.0.10 版本。

多线程初始化

void initThreadedIO(void) {
    server.io_threads_active = 0; /* We start with threads not active. */

    // 如果用户只配置了一个 I/O 线程,则不会创建新线程(效率低),直接在主线程里处理 I/O。
    if (server.io_threads_num == 1) return;

    if (server.io_threads_num > IO_THREADS_MAX_NUM) {
        serverLog(LL_WARNING,"Fatal: too many I/O threads configured. "
                             "The maximum number is %d.", IO_THREADS_MAX_NUM);
        exit(1);
    }

    // 根据用户配置的 I/O 线程数,启动线程。
    for (int i = 0; i < server.io_threads_num; i++) {
        // 初始化 I/O 线程的本地任务队列。
        io_threads_list[i] = listCreate();
        if (i == 0) continue; // 线程 0 是主线程。

        // 初始化 I/O 线程并启动。
        pthread_t tid;
        // 每个 I/O 线程会分配一个本地锁,用来休眠和唤醒线程。
        pthread_mutex_init(&io_threads_mutex[i],NULL);
        // 每个 I/O 线程分配一个原子计数器,用来记录当前遗留的任务数量。
        io_threads_pending[i] = 0;
        // 主线程在启动 I/O 线程的时候会默认先锁住它,直到有 I/O 任务才唤醒它。
        pthread_mutex_lock(&io_threads_mutex[i]);
        // 启动线程,进入 I/O 线程的主逻辑函数 IOThreadMain。
        if (pthread_create(&tid,NULL,IOThreadMain,(void*)(long)i) != 0) {
            serverLog(LL_WARNING,"Fatal: Can't initialize IO thread.");
            exit(1);
        }
        io_threads[i] = tid;
    }
}

initThreadedIO 会在 Redis 服务器启动时的初始化工作的末尾被调用,初始化 I/O 多线程并启动。

Redis 的多线程模式默认是关闭的,需要用户在 redis.conf 配置文件中开启:

io-threads 4
io-threads-do-reads yes

读取请求

当客户端发送请求命令之后,会触发 Redis 主线程的事件循环,命令处理器 readQueryFromClient 被回调,在以前的单线程模型下,这个方法会直接读取解析客户端命令并执行,但是多线程模式下,则会把 client 加入到 clients_pending_read 任务队列中去,后面主线程再分配到 I/O 线程去读取客户端请求命令:

void readQueryFromClient(connection *conn) {
    client *c = connGetPrivateData(conn);
    int nread, readlen;
    size_t qblen;

    // 检查是否开启了多线程,如果是则把 client 加入异步队列之后返回。
    if (postponeClientRead(c)) return;
    
    // 省略代码,下面的代码逻辑和单线程版本几乎是一样的。
    ... 
}

int postponeClientRead(client *c) {
    // 当多线程 I/O 模式开启、主线程没有在处理阻塞任务时,将 client 加入异步队列。
    if (server.io_threads_active &&
        server.io_threads_do_reads &&
        !ProcessingEventsWhileBlocked &&
        !(c->flags & (CLIENT_MASTER|CLIENT_SLAVE|CLIENT_PENDING_READ)))
    {
        // 给 client 打上 CLIENT_PENDING_READ 标识,表示该 client 需要被多线程处理,
        // 后续在 I/O 线程中会在读取和解析完客户端命令之后判断该标识并放弃执行命令,让主线程去执行。
        c->flags |= CLIENT_PENDING_READ;
        listAddNodeHead(server.clients_pending_read,c);
        return 1;
    } else {
        return 0;
    }
}

接着主线程会在事件循环的 beforeSleep() 方法中,调用 handleClientsWithPendingReadsUsingThreads

int handleClientsWithPendingReadsUsingThreads(void) {
    if (!server.io_threads_active || !server.io_threads_do_reads) return 0;
    int processed = listLength(server.clients_pending_read);
    if (processed == 0) return 0;

    if (tio_debug) printf("%d TOTAL READ pending clients\n", processed);

    // 遍历待读取的 client 队列 clients_pending_read,
    // 通过 RR 轮询均匀地分配给 I/O 线程和主线程自己(编号 0)。
    listIter li;
    listNode *ln;
    listRewind(server.clients_pending_read,&li);
    int item_id = 0;
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        int target_id = item_id % server.io_threads_num;
        listAddNodeTail(io_threads_list[target_id],c);
        item_id++;
    }

    // 设置当前 I/O 操作为读取操作,给每个 I/O 线程的计数器设置分配的任务数量,
    // 让 I/O 线程可以开始工作:只读取和解析命令,不执行。
    io_threads_op = IO_THREADS_OP_READ;
    for (int j = 1; j < server.io_threads_num; j++) {
        int count = listLength(io_threads_list[j]);
        io_threads_pending[j] = count;
    }

    // 主线程自己也会去执行读取客户端请求命令的任务,以达到最大限度利用 CPU。
    listRewind(io_threads_list[0],&li);
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        readQueryFromClient(c->conn);
    }
    listEmpty(io_threads_list[0]);

    // 忙轮询,累加所有 I/O 线程的原子任务计数器,直到所有计数器的遗留任务数量都是 0,
    // 表示所有任务都已经执行完成,结束轮询。
    while(1) {
        unsigned long pending = 0;
        for (int j = 1; j < server.io_threads_num; j++)
            pending += io_threads_pending[j];
        if (pending == 0) break;
    }
    if (tio_debug) printf("I/O READ All threads finshed\n");

    // 遍历待读取的 client 队列,清除 CLIENT_PENDING_READ 和 CLIENT_PENDING_COMMAND 标记,
    // 然后解析并执行所有 client 的命令。
    while(listLength(server.clients_pending_read)) {
        ln = listFirst(server.clients_pending_read);
        client *c = listNodeValue(ln);
        c->flags &= ~CLIENT_PENDING_READ;
        listDelNode(server.clients_pending_read,ln);

        if (c->flags & CLIENT_PENDING_COMMAND) {
            c->flags &= ~CLIENT_PENDING_COMMAND;
            // client 的第一条命令已经被解析好了,直接尝试执行。
            if (processCommandAndResetClient(c) == C_ERR) {
                /* If the client is no longer valid, we avoid
                 * processing the client later. So we just go
                 * to the next. */
                continue;
            }
        }
        processInputBuffer(c); // 继续解析并执行 client 命令。

        // 命令执行完成之后,如果 client 中有响应数据需要回写到客户端,则将 client 加入到待写出队列 clients_pending_write
        if (!(c->flags & CLIENT_PENDING_WRITE) && clientHasPendingReplies(c))
            clientInstallWriteHandler(c);
    }

    /* Update processed count on server */
    server.stat_io_reads_processed += processed;

    return processed;
}

这里的核心工作是:

  • 遍历待读取的 client 队列 clients_pending_read,通过 RR 策略把所有任务分配给 I/O 线程和主线程去读取和解析客户端命令。
  • 忙轮询等待所有 I/O 线程完成任务。
  • 最后再遍历 clients_pending_read,执行所有 client 的命令。

写回响应

完成命令的读取、解析以及执行之后,客户端命令的响应数据已经存入 client->buf 或者 client->reply 中了,接下来就需要把响应数据回写到客户端了,还是在 beforeSleep 中, 主线程调用 handleClientsWithPendingWritesUsingThreads

int handleClientsWithPendingWritesUsingThreads(void) {
    int processed = listLength(server.clients_pending_write);
    if (processed == 0) return 0; /* Return ASAP if there are no clients. */

    // 如果用户设置的 I/O 线程数等于 1 或者当前 clients_pending_write 队列中待写出的 client
    // 数量不足 I/O 线程数的两倍,则不用多线程的逻辑,让所有 I/O 线程进入休眠,
    // 直接在主线程把所有 client 的相应数据回写到客户端。
    if (server.io_threads_num == 1 || stopThreadedIOIfNeeded()) {
        return handleClientsWithPendingWrites();
    }

    // 唤醒正在休眠的 I/O 线程(如果有的话)。
    if (!server.io_threads_active) startThreadedIO();

    if (tio_debug) printf("%d TOTAL WRITE pending clients\n", processed);

    // 遍历待写出的 client 队列 clients_pending_write,
    // 通过 RR 轮询均匀地分配给 I/O 线程和主线程自己(编号 0)。
    listIter li;
    listNode *ln;
    listRewind(server.clients_pending_write,&li);
    int item_id = 0;
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        c->flags &= ~CLIENT_PENDING_WRITE;

        /* Remove clients from the list of pending writes since
         * they are going to be closed ASAP. */
        if (c->flags & CLIENT_CLOSE_ASAP) {
            listDelNode(server.clients_pending_write, ln);
            continue;
        }

        int target_id = item_id % server.io_threads_num;
        listAddNodeTail(io_threads_list[target_id],c);
        item_id++;
    }

    // 设置当前 I/O 操作为写出操作,给每个 I/O 线程的计数器设置分配的任务数量,
    // 让 I/O 线程可以开始工作,把写出缓冲区(client->buf 或 c->reply)中的响应数据回写到客户端。
    io_threads_op = IO_THREADS_OP_WRITE;
    for (int j = 1; j < server.io_threads_num; j++) {
        int count = listLength(io_threads_list[j]);
        io_threads_pending[j] = count;
    }

    // 主线程自己也会去执行读取客户端请求命令的任务,以达到最大限度利用 CPU。
    listRewind(io_threads_list[0],&li);
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        writeToClient(c,0);
    }
    listEmpty(io_threads_list[0]);

    // 忙轮询,累加所有 I/O 线程的原子任务计数器,直到所有计数器的遗留任务数量都是 0。
    // 表示所有任务都已经执行完成,结束轮询。
    while(1) {
        unsigned long pending = 0;
        for (int j = 1; j < server.io_threads_num; j++)
            pending += io_threads_pending[j];
        if (pending == 0) break;
    }
    if (tio_debug) printf("I/O WRITE All threads finshed\n");

    // 最后再遍历一次 clients_pending_write 队列,检查是否还有 client 的写出缓冲区中有残留数据,
    // 如果有,那就为 client 注册一个命令回复器 sendReplyToClient,等待客户端写就绪再继续把数据回写。
    listRewind(server.clients_pending_write,&li);
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);

        // 检查 client 的写出缓冲区是否还有遗留数据。
        if (clientHasPendingReplies(c) &&
                connSetWriteHandler(c->conn, sendReplyToClient) == AE_ERR)
        {
            freeClientAsync(c);
        }
    }
    listEmpty(server.clients_pending_write);

    /* Update processed count on server */
    server.stat_io_writes_processed += processed;

    return processed;
}

这里的核心工作是:

  • 检查当前任务负载,如果当前的任务数量不足以用多线程模式处理的话,则休眠 I/O 线程并且直接同步将响应数据回写到客户端。
  • 唤醒正在休眠的 I/O 线程(如果有的话)。
  • 遍历待写出的 client 队列 clients_pending_write,通过 RR 策略把所有任务分配给 I/O 线程和主线程去将响应数据写回到客户端。
  • 忙轮询等待所有 I/O 线程完成任务。
  • 最后再遍历 clients_pending_write,为那些还残留有响应数据的 client 注册命令回复处理器 sendReplyToClient,等待客户端可写之后在事件循环中继续回写残余的响应数据。

I/O 线程主逻辑

void *IOThreadMain(void *myid) {
    /* The ID is the thread number (from 0 to server.iothreads_num-1), and is
     * used by the thread to just manipulate a single sub-array of clients. */
    long id = (unsigned long)myid;
    char thdname[16];

    snprintf(thdname, sizeof(thdname), "io_thd_%ld", id);
    redis_set_thread_title(thdname);
    // 设置 I/O 线程的 CPU 亲和性,尽可能将 I/O 线程(以及主线程,不在这里设置)绑定到用户配置的
    // CPU 列表上。
    redisSetCpuAffinity(server.server_cpulist);
    makeThreadKillable();

    while(1) {
        // 忙轮询,100w 次循环,等待主线程分配 I/O 任务。
        for (int j = 0; j < 1000000; j++) {
            if (io_threads_pending[id] != 0) break;
        }

        // 如果 100w 次忙轮询之后如果还是没有任务分配给它,则通过尝试加锁进入休眠,
        // 等待主线程分配任务之后调用 startThreadedIO 解锁,唤醒 I/O 线程去执行。
        if (io_threads_pending[id] == 0) {
            pthread_mutex_lock(&io_threads_mutex[id]);
            pthread_mutex_unlock(&io_threads_mutex[id]);
            continue;
        }

        serverAssert(io_threads_pending[id] != 0);

        if (tio_debug) printf("[%ld] %d to handle\n", id, (int)listLength(io_threads_list[id]));


        // 注意:主线程分配任务给 I/O 线程之时,
        // 会把任务加入每个线程的本地任务队列 io_threads_list[id],
        // 但是当 I/O 线程开始执行任务之后,主线程就不会再去访问这些任务队列,避免数据竞争。
        listIter li;
        listNode *ln;
        listRewind(io_threads_list[id],&li);
        while((ln = listNext(&li))) {
            client *c = listNodeValue(ln);
            // 如果当前是写出操作,则把 client 的写出缓冲区中的数据回写到客户端。
            if (io_threads_op == IO_THREADS_OP_WRITE) {
                writeToClient(c,0);
              // 如果当前是读取操作,则socket 读取客户端的请求命令并解析第一条命令。
            } else if (io_threads_op == IO_THREADS_OP_READ) {
                readQueryFromClient(c->conn);
            } else {
                serverPanic("io_threads_op value is unknown");
            }
        }
        listEmpty(io_threads_list[id]);
        // 所有任务执行完之后把自己的计数器置 0,主线程通过累加所有 I/O 线程的计数器
        // 判断是否所有 I/O 线程都已经完成工作。
        io_threads_pending[id] = 0;

        if (tio_debug) printf("[%ld] Done\n", id);
    }
}

I/O 线程启动之后,会先进入忙轮询,判断原子计数器中的任务数量,如果是非 0 则表示主线程已经给它分配了任务,开始执行任务,否则就一直忙轮询一百万次等待,忙轮询结束之后再查看计数器,如果还是 0,则尝试加本地锁,因为主线程在启动 I/O 线程之时就已经提前锁住了所有 I/O 线程的本地锁,因此 I/O 线程会进行休眠,等待主线程唤醒。

主线程会在每次事件循环中尝试调用 startThreadedIO 唤醒 I/O 线程去执行任务,如果接收到客户端请求命令,则 I/O 线程会被唤醒开始工作,根据主线程设置的 io_threads_op 标识去执行命令读取和解析或者回写响应数据的任务,I/O 线程在收到主线程通知之后,会遍历自己的本地任务队列 io_threads_list[id],取出一个个 client 执行任务:

  • 如果当前是写出操作,则调用 writeToClient,通过 socket 把 client->buf 或者 client->reply 里的响应数据回写到客户端。
  • 如果当前是读取操作,则调用 readQueryFromClient,通过 socket 读取客户端命令,存入 client->querybuf,然后调用 processInputBuffer 去解析命令,这里最终只会解析到第一条命令,然后就结束,不会去执行命令。
  • 在全部任务执行完之后把自己的原子计数器置 0,以告知主线程自己已经完成了工作。
void processInputBuffer(client *c) {
// 省略代码
...

    while(c->qb_pos < sdslen(c->querybuf)) {
        /* Return if clients are paused. */
        if (!(c->flags & CLIENT_SLAVE) && clientsArePaused()) break;

        /* Immediately abort if the client is in the middle of something. */
        if (c->flags & CLIENT_BLOCKED) break;

        /* Don't process more buffers from clients that have already pending
         * commands to execute in c->argv. */
        if (c->flags & CLIENT_PENDING_COMMAND) break;
        /* Multibulk processing could see a <= 0 length. */
        if (c->argc == 0) {
            resetClient(c);
        } else {
            // 判断 client 是否具有 CLIENT_PENDING_READ 标识,如果是处于多线程 I/O 的模式下,
            // 那么此前已经在 readQueryFromClient -> postponeClientRead 中为 client 打上该标识,
            // 则立刻跳出循环结束,此时第一条命令已经解析完成,但是不执行命令。
            if (c->flags & CLIENT_PENDING_READ) {
                c->flags |= CLIENT_PENDING_COMMAND;
                break;
            }

            // 执行客户端命令
            if (processCommandAndResetClient(c) == C_ERR) {
                /* If the client is no longer valid, we avoid exiting this
                 * loop and trimming the client buffer later. So we return
                 * ASAP in that case. */
                return;
            }
        }
    }

...
}

这里需要额外关注 I/O 线程初次启动时会设置当前线程的 CPU 亲和性,也就是绑定当前线程到用户配置的 CPU 上,在启动 Redis 服务器主线程的时候同样会设置 CPU 亲和性,Redis 的核心网络模型引入多线程之后,加上之前的多线程异步任务、多进程(BGSAVE、AOF、BIO、Sentinel 脚本任务等),Redis 现如今的系统并发度已经很大了,而 Redis 本身又是一个对吞吐量和延迟极度敏感的系统,所以用户需要 Redis 对 CPU 资源有更细粒度的控制,这里主要考虑的是两方面:CPU 高速缓存和 NUMA 架构。

首先是 CPU 高速缓存(这里讨论的是 L1 Cache 和 L2 Cache 都集成在 CPU 中的硬件架构),这里想象一种场景:Redis 主进程正在 CPU-1 上运行,给客户端提供数据服务,此时 Redis 启动了子进程进行数据持久化(BGSAVE 或者 AOF),系统调度之后子进程抢占了主进程的 CPU-1,主进程被调度到 CPU-2 上去运行,导致之前 CPU-1 的高速缓存里的相关指令和数据被汰换掉,CPU-2 需要重新加载指令和数据到自己的本地高速缓存里,浪费 CPU 资源,降低性能。

因此,Redis 通过设置 CPU 亲和性,可以将主进程/线程和子进程/线程绑定到不同的核隔离开来,使之互不干扰,能有效地提升系统性能。

其次是基于 NUMA 架构的考虑,在 NUMA 体系下,内存控制器芯片被集成到处理器内部,形成 CPU 本地内存,访问本地内存只需通过内存通道而无需经过系统总线,访问时延大大降低,而多个处理器之间通过 QPI 数据链路互联,跨 NUMA 节点的内存访问开销远大于本地内存的访问:

因此,Redis 通过设置 CPU 亲和性,让主进程/线程尽可能在固定的 NUMA 节点上的 CPU 上运行,更多地使用本地内存而不需要跨节点访问数据,同样也能大大地提升性能。

关于 NUMA 相关知识请读者自行查阅,篇幅所限这里就不再展开,以后有时间我再单独写一篇文章介绍。

最后还有一点,阅读过源码的读者可能会有疑问,Redis 的多线程模式下,似乎并没有对数据进行锁保护,事实上 Redis 的多线程模型是全程无锁(Lock-free)的,这是通过原子操作+交错访问来实现的,主线程和 I/O 线程之间共享的变量有三个:io_threads_pending 计数器、io_threads_op I/O 标识符和 io_threads_list 线程本地任务队列。

io_threads_pending 是原子变量,不需要加锁保护,io_threads_opio_threads_list 这两个变量则是通过控制主线程和 I/O 线程交错访问来规避共享数据竞争问题:I/O 线程启动之后会通过忙轮询和锁休眠等待主线程的信号,在这之前它不会去访问自己的本地任务队列 io_threads_list[id],而主线程会在分配完所有任务到各个 I/O 线程的本地队列之后才去唤醒 I/O 线程开始工作,并且主线程之后在 I/O 线程运行期间只会访问自己的本地任务队列 io_threads_list[0] 而不会再去访问 I/O 线程的本地队列,这也就保证了主线程永远会在 I/O 线程之前访问 io_threads_list 并且之后不再访问,保证了交错访问。io_threads_op 同理,主线程会在唤醒 I/O 线程之前先设置好 io_threads_op 的值,并且在 I/O 线程运行期间不会再去访问这个变量。

性能提升

Redis 将核心网络模型改造成多线程模式追求的当然是最终性能上的提升,所以最终还是要以 benchmark 数据见真章:

测试数据表明,Redis 在使用多线程模式之后性能大幅提升,达到了一倍。更详细的性能压测数据可以参阅这篇文章:Benchmarking the experimental Redis Multi-Threaded I/O

以下是美图技术团队实测的新旧 Redis 版本性能对比图,仅供参考:

模型缺陷

首先第一个就是我前面提到过的,Redis 的多线程网络模型实际上并不是一个标准的 Multi-Reactors/Master-Workers 模型,和其他主流的开源网络服务器的模式有所区别,最大的不同就是在标准的 Multi-Reactors/Master-Workers 模式下,Sub Reactors/Workers 会完成 网络读 -> 数据解析 -> 命令执行 -> 网络写 整套流程,Main Reactor/Master 只负责分派任务,而在 Redis 的多线程方案中,I/O 线程任务仅仅是通过 socket 读取客户端请求命令并解析,却没有真正去执行命令,所有客户端命令最后还需要回到主线程去执行,因此对多核的利用率并不算高,而且每次主线程都必须在分配完任务之后忙轮询等待所有 I/O 线程完成任务之后才能继续执行其他逻辑。

Redis 之所以如此设计它的多线程网络模型,我认为主要的原因是为了保持兼容性,因为以前 Redis 是单线程的,所有的客户端命令都是在单线程的事件循环里执行的,也因此 Redis 里所有的数据结构都是非线程安全的,现在引入多线程,如果按照标准的 Multi-Reactors/Master-Workers 模式来实现,则所有内置的数据结构都必须重构成线程安全的,这个工作量无疑是巨大且麻烦的。

所以,在我看来,Redis 目前的多线程方案更像是一个折中的选择:既保持了原系统的兼容性,又能利用多核提升 I/O 性能。

其次,目前 Redis 的多线程模型中,主线程和 I/O 线程的通信过于简单粗暴:忙轮询和锁,因为通过自旋忙轮询进行等待,导致 Redis 在启动的时候以及运行期间偶尔会有短暂的 CPU 空转引起的高占用率,而且这个通信机制的最终实现看起来非常不直观和不简洁,希望后面 Redis 能对目前的方案加以改进。

总结

Redis 作为缓存系统的事实标准,它的底层原理值得开发者去深入学习,Redis 自 2009 年发布第一版之后,其单线程网络模型的选择在社区中从未停止过讨论,多年来一直有呼声希望 Redis 能引入多线程从而利用多核优势,但是作者 antirez 是一个追求大道至简的开发者,对 Redis 加入任何新功能都异常谨慎,所以在 Redis 初版发布的十年后才最终将 Redis 的核心网络模型改造成多线程模式,这期间甚至诞生了一些 Redis 多线程的替代项目。虽然 antirez 一直在推迟多线程的方案,但却从未停止思考多线程的可行性,Redis 多线程网络模型的改造不是一朝一夕的事情,这其中牵扯到项目的方方面面,所以我们可以看到 Redis 的最终方案也并不完美,没有采用主流的多线程模式设计。

让我们来回顾一下 Redis 多线程网络模型的设计方案:

  • 使用 I/O 线程实现网络 I/O 多线程化,I/O 线程只负责网络 I/O 和命令解析,不执行客户端命令。
  • 利用原子操作+交错访问实现无锁的多线程模型。
  • 通过设置 CPU 亲和性,隔离主进程和其他子进程,让多线程网络模型能发挥最大的性能。

通读本文之后,相信读者们应该能够了解到一个优秀的网络系统的实现所涉及到的计算机领域的各种技术:设计模式、网络 I/O、并发编程、操作系统底层,甚至是计算机硬件。另外还需要对项目迭代和重构的谨慎,对技术方案的深入思考,绝不仅仅是写好代码这一个难点。

参考&延伸阅读

查看原文

认证与成就

  • 获得 8 次点赞
  • 获得 110 枚徽章 获得 3 枚金徽章, 获得 25 枚银徽章, 获得 82 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

  • 网易教育产品部

    由于本人是网易云课堂的忠实用户,云课堂课程的种类繁多,因此想制作一个网站,只把本人喜欢的课程加进去。其中使用纯js写了登录框,并实现了轮播图,滚动图,悬浮层等效果,与后台通信采用的ajax技术

注册于 2013-05-22
个人主页被 1.2k 人浏览