张俊强 腾讯互娱工程师,目前负责腾讯互娱心悦俱乐部的后台开发,先后参与过心悦用户体系下沉,后台服务协程化改造,心悦积分体系搭建等项目,致力于海量、高可用、高性能的分布式系统设计及研发。 改造背景 工作后一直在做c++后台服务开发,框架基本都是多进程多线程的模型,也基本能解决绝大部分问题。不同的应用场景下,可以通过同步或者异步的方式来满足业务或者性能的要求。 但是如果原有业务是同步方式实现的,如果性能需要优化改为异步,一般都是通过重构服务来实现,重构的过程大家都懂的,特别是涉及到整个框架的异步化重构,是很痛苦
第一次接触协程这个概念,是在学习Swoole时,那时看官方文档并不能完全理解协程到底是个什么东西以及该如何正确的使用它。
本⽂以爱奇艺开源的⽹络协程库(https://github.com/iqiyi/libfiber )为例,讲解⽹络协程的设计原理、编程实践、性能优化等⽅⾯内容。
本⽂以爱奇艺开源的⽹络协程库(https://www.jintianxuesha.com)为例,讲解⽹络协程的设计原理、编程实践、性能优化等⽅⾯内容。
warning: 这篇文章距离上次修改已过188天,其中的内容可能已经有所变动。
Linux 按照特权等级,把进程的运行空间分为内核空间和用户空间,一次系统调用可以实现用户态和内核态的切换
协程可以简单理解为线程,只不过这个线程是用户态的,不需要操作系统参与,创建销毁和切换的成本非常低,和线程不同的是协程没法利用多核 cpu 的,想利用多核 cpu 需要依赖 Swoole 的多进程模型。
Rust作为一门新兴语言,主打系统编程。提供了多种编写代码的模式。2019年底正式推出了 async/await语法,标志着Rust也进入了协程时代。下面让我们来看一看。Rust协程和Go协程究竟有什么不同。
libco简介 libco是微信后台大规模使用的c/c++协程库,2013年至今稳定运行在微信后台的数万台机器上,使得微信后端服务能同时hold大量请求,被誉为微信服务器稳定性的基石。libco在2013年的时候作为腾讯六大开源项目首次开源。libco源码地址。 libco首先能解决CPU利用率与IO利用率不平衡,比用多线程解决IO阻塞CPU问题更高效。因为用户态协程切换比线程切换性能高:线程切换保存恢复的数据更多,需要用户态和内核态切换。其次libco又避免了异步调用和回调分离导致的代码结构破碎。
如果说,在OS中引入进程的目的是为了使多个程序能并发执行,以提高资源利用率和系统吞吐量,那么,在操作系统中再引入线程,则是为了减少程序在并发执行时所付出的时空开销,使OS具有更好的并发性。为什么?
libco是微信后台大规模使用的c/c++协程库,2013年至今稳定运行在微信后台的数万台机器上,使得微信后端服务能同时hold大量请求,被誉为微信服务器稳定性的基石。libco在2013年的时候作为腾讯六大开源项目首次开源。libco源码地址。
在说go协程之前,先对比看一下进程&线程&协程这几个基础的概念。 进程是指一段程序的执行过程,具有自己的地址空间(包括文本区域(text region)、数据区域(data region)和堆栈(stack region)),并且进程由cpu直接负责调度控制。 线程是CPU调度的最小单位,线程只是一个进程中的不同执行路径。线程有自己的堆栈和局部变量,但线程之间没有单独的地址空间。同样是由cpu直接负责调度控制的。 协程可以理解为是用户级线程,对于协程来说对内核透明的,也就是系统并不知道有协程的存在,是完全由用户自己的程序进行调度的,cpu对于我们的协程无感知。 goroutine实际上就是协程,为什么叫做go协程呢,因为go在runtime、系统调用方面对goroutine调度进行了封装和处理,也就是说go在语言层面实现对于go协程的支持:使用go 关键字就可以了。 内存消耗方面: 每个 goroutine (协程) 默认占用内存远比 Java 、C 的线程少。 goroutine:2KB 线程:8MB 线程和 goroutine 切换调度开销方面: 线程/goroutine 切换开销方面,goroutine 远比线程小 线程:涉及模式切换(从用户态切换到内核态)、16个寄存器、PC、SP...等寄存器的刷新等。 goroutine:只有三个寄存器的值修改 - PC / SP / DX. 最主要的是不担心协程间切换、或者协程打满或者夯死。 关于协程协程这类知识,感觉先说原理再说使用会比较理解,后面就先来看下go协程的实现原理。
Jetpack Room 对协程的支持越来越丰富: Room 2.1 版本增加了对协程的支持,并加入了一次性 (one-shot) 的读写操作,Room 2.2 我们通过 Flow 为读操作加入了可观察性,当数据库中的数据有变化时它可以使您收到通知。
协程(Coroutines)是一种比线程更加轻量级的存在。协程完全由程序所控制(在用户态执行),带来的好处是性能大幅度的提升。 一个操作系统中可以有多个进程;一个进程可以有多个线程;同理,一个线程可以有多个协程。
不知从几何起,可能是大三那年的操作系统考试,也可能是刚经历完的秋招,这些概念总是迷迷糊糊,可能自己回答的和其他人的答复也差不多,并没有什么亮点,通常都会以:「我们换个题」的方式结束,有时候也挺尴尬的。我们不妨看看这样几个题应该怎么去回答
有栈协程是基于函数切换上下文恢复的思路实现被中断协程的继续执行,但是这个上下文里面有返回地址,即下一条指令的地址,所以当程序发生改动重新编译生成,指令地址有可能发生改变,这种对于需要重新编译生成发布的发布场景支持并不友好,会因为程序指令地址的变化导致协程执行流的错乱。这时另外一种不基于上下文恢复的协程机制提供了一种新的思路。
协程,英文Coroutines,是一种比线程更加轻量级的存在。正如一个进程可以拥有多个线程一样,一个线程也可以拥有多个协程。
runtime 包 提供了运行时与系统的交互,比如控制协程函数,触发垃圾立即回收等等底层操作,下面我们就运行时能做的所有事情逐个进行说明与代码演示
之前用 go 写一个小工具的时候, 用到了多个协程之间的通信, 当时随手查了查, 结果查出来一大坨, 简单记录一下. golang中多个协程之间是如何进行通信及数据同步的嘞.
实际上,出现上述的情况,还是因为我们对于 GO 语言的并发模型和涉及的 GO 语言基础不够扎实,误解了语言的用法。
要是对协程的使用感兴趣的话,可以看看这篇文章简单了解一下瞅一眼就会使用GO的并发编程分享
进程-操作系统提供的抽象概念,是系统进行资源分配和调度的基本单位,是操作系统结构的基础。程序是指令、数据及其组织形式的描述,进程是程序的实体。程序本身是没有生命周期的,它只是存在磁盘上的一些指令,程序一旦运行就是进程。
这阵子一有空就在研究Unity3D网络通讯,使用过程中访问通过协程的方式收到返回的数据直接更新Text的显示值都没有问题,结果在处理Socket通讯TCP方式采用异步时遇到了问题,本章主要就是记录一下测试的过程和处理方法,关于Unity3D与后台的网络通讯这块后面会有一个系列发出来。
coroutine库是云风大佬以前写的一个协程库,短小精悍,源码分析在这(https://github.com/theanarkh/read-coroutine-code)。今天就分析一下这个库的原理。话不多说,直接开始。 首先了解一下数据结构。
https://cloud.tencent.com/developer/article/2375995
作为即时通讯技术的开发者来说,高性能、高并发相关的技术概念早就了然与胸,什么线程池、零拷贝、多路复用、事件驱动、epoll等等名词信手拈来,又或许你对具有这些技术特征的技术框架比如:Java的Netty、Php的workman、Go的gnet等熟练掌握。但真正到了面视或者技术实践过程中遇到无法释怀的疑惑时,方知自已所掌握的不过是皮毛。
在高并发的场景下,python提供了一个多线程的模块threading,但似乎这个模块并不近人如意,原因在于cpython本身的全局解析锁(GIL)问题,在一段时间片内实际上的执行是单线程的。同时还存在着资源争夺的问题。python3.4之后引入了基于生成器对象的协程概念。也就是asyncio模块。除了asyncio模块,python在高并发这一问题还提出了另外一些解决方案,例如tornado和gevent都实现了类似的功能。由此,在方案选择上提供了更多的可能性。以下是threading模块和asyncio模块对比测试实验。asyncio模块的具体使用,我希望自己在另一篇文章再写。
协程 在 调用 call 和 返回 return 基础上 , 又新增了两种 状态 :
今天穿插一篇底软文章,“【硬件篇】VCU软件接口原理”尚未更新完,预计会在10篇以上,大家可以继续保持关注。本文介绍一种事件驱动模型“protothreads”,由瑞典SICS的Adam Dunkels开发,也是Contiki OS中的源代码,此模型适合应用于资源受限的嵌入式系统中,当然我也曾用于某项目的开发中,受益匪浅,独乐乐不如众乐乐,今天分享给大家,所讲细节不一定面面俱到,不足之处还请指教。
goroutine作为Golang并发的核心,我们不仅要关注它们的创建和管理,当然还要关注如何合理的退出这些协程,不(合理)退出不然可能会造成阻塞、panic、程序行为异常、数据结果不正确等问题。这篇文章介绍,如何合理的退出goroutine,减少软件bug。
这篇文章将介绍Golang并发编程中常用到一种编程模式:context。本文将从为什么需要context出发,深入了解context的实现原理,以及了解如何使用context。
VictoriaMetrics监控组件(以下简称VM)号称比Prometheus快了至少3倍,内存占用比Prometheus小了7倍。
在某些场景下,我们需要初始化一些资源,例如单例对象、配置等。实现资源的初始化有多种方法,如定义 package 级别的变量、在 init 函数中进行初始化,或者在 main 函数中进行初始化。这三种方式都能确保并发安全,并在程序启动时完成资源的初始化。
用俗语来说,锁意味着一种保护,对资源的一种保护,在程序员眼中,这个资源可以是一个变量,一个代码片段,一条记录,一张数据库表等等。
在java/c++中要实现并发编程的时候,通常需要自己维护一个线程池,并且需要自己去包装一个又一个的任务,同时需要自己去调度线程执行任务并维护上下文切换,这一切通常会耗费程序员大量的心智
既然本系列讲的是基于汇编的 C/C++ 协程,那么这篇文章我们就来讲讲使用汇编来进行上下文切换的原理。
在讲协程之前,先回顾C11之前我们怎么处理多任务,怎么同步不同任务之间的处理顺序。想象一个你在用文本编辑器GUI,你对GUI的每个button进行操作,背后都有一段函数代码处理你的button事件。这就是事件驱动。事件驱动代码的一个典型示例是注册一个回调,每次套接字有数据要读取时都会调用该回调。
从后台工程师的角度说,有栈协程的应用更普遍。例如,云风封装的非常经典的基于C的ucontext.h来实现的共享栈的协程,具体请见《C 的 coroutine 库》。而golang在语言级实现的协程是独立栈的协程。
我们终于在年初的时候最后完成了整体服务器框架对C++20协程的支持和接入。虽然之前陆陆续续抽时间改造一些组件,让它支持C++20协程,期间也记录了一些早期的设计思路和踩的坑(包括 《libcopp接入C++20 Coroutine和一些过渡期的设计》和《libcopp对C++20协程的接入和接口设计》),其中不乏一些C++20协程使用上可能打破我们常规思路细节和编译器的BUG。而且这些都是各个组件的改造,并没有最后整合到一起。
作为 Kotlin Multiplatform 体系重要组成部分之一的 Kotlin/Native ,目前还是一项处于 beta 阶段的技术。而 Kotlin/Native与 Kotlin/JVM 的异步并发模型也有着极大的不同,因此如果要实践 Kotlin Multiplatform,则事先对 Kotlin/Native的异步并发模型进行探究就显得很有必要。
关于Lifecycle的基本使用,这里就不详细介绍了,毕竟官网讲的很清楚了,而且大部分时间,我们也用太感知细节,这也是JetPack的魅力所在。
经典定义:一个执行中程序的实例。系统中的每个程序都运行在某个进程的上下文中。(-摘自 CSAPP)
与其他编程语言相比,C++ 加入协程较晚,从C++20开始支持。在协程出现之前,C++ 程序员有两种选择:
静态编译 编译时一个将源代码翻译成低级语言的过程。编译过程比较慢,在设计Go时,编译速度是主要的设计目标之一。静态类型意味着变量必须指定一个类型,如整形,字符串,布尔,数组等,可以在声明变量时指定变量类型,大多数情况下,让编译器自动去推断变量类型。 垃圾回收 变量有一个确定的生命周期。例如函数中定义的局部变量,当函数退出时变量就不存在了。语言的垃圾回收机制可以记录不在使用的变量,然后释放他们占用的内存。垃圾回收机制带来一些性能影响。 代码运行 go run命令会先编译然后再运行你的代码,会在一个临时目录下编
协程:是单线程下的并发,又称微线程,纤程。英文名Coroutine。是一种用户态的轻量级线程,即协程是由用户程序自己控制调度的。
上一章节介绍了协程的现状,并以libco为例介绍了主流有栈协程的实现原理。这一篇,我们开始进入C++20原生协程的研究。
后台架构的微服务化,原先的单体应用被按照功能模块切分为若干进程组承担,此种架构演化带来的收益诸如:
领取专属 10元无门槛券
手把手带您无忧上云