标签 并发 下的文章

Rust vs. Go:为什么强强联合会更好

本文翻译自乔纳森·特纳(Jonathan Turner)和史蒂夫·弗朗西亚(Steve Francia)的文章《Rust vs. Go: Why They’re Better Together》

史蒂夫·弗朗西亚(Steve Francia):在过去的25年里,Steve Francia建立了一些最具创新性和成功的技术和公司,这些技术和公司已经成为云计算的基础,被全世界的企业和开发者所接受。他目前是谷歌Go编程语言的产品和战略负责人。他是Hugo、Cobra、Viper、spf13-vim和许多其他开源项目的创建者,拥有领导世界上最大的五个开源项目的独特荣誉。

乔纳森-特纳(Jonathan Turner)在开源领域工作了20多年,从小型项目到大型项目,包括帮助微软向开源转型。他是创建TypeScript团队的一员,并作为项目经理和设计团队的负责人帮助其成长。他还作为Rust社区成员和Mozilla Rust团队的一员参与Rust的工作,包括共同设计Rust的错误信息和IDE支持。

虽然其他人可能认为RustGo是竞争性的编程语言,但Rust和Go团队却都不这么认为。恰恰相反,我们的团队非常尊重其他团队正在做的事情,并认为这两种编程语言是相辅相成的,有着共同的愿景,即在整个行业内实现软件开发状态的现代化。

在本文中,我们将讨论Rust和Go的优缺点、它们如何相互补充和支持以及我们对每种语言的最佳使用时机的建议。

一些公司正在发掘采用这两种语言的价值以及它们的互补价值。为了从我们的观点转向用户的实际体验,我们采访了三家这样的公司,DropboxFastlyCloudflare,讲述了他们共同使用Go和Rust的经验。他们的经验之谈将被引用并贯穿本文,为大家提供更进一步的观点。

1. 语言比较

编程语言 Go Rust
创建时间 2009 2010
创建于 谷歌 Mozilla
知名项目 Kubernetes,Docker,Github CLI,Hugo,Caddy,Drone,Ethereum,Syncthing,Terraform Firefox, ripgrep, alacritty, deno, Habitat
典型用途 APIs, Web Apps, CLI apps, DevOps, Networking, Data Processing, cloud apps IoT, processing engines, security-sensitive apps, system components, cloud apps
开发者采用 8.8%(第12名) 5.1%(第19名)
开发者最爱 62.3%(第5名) 86.1%(第1名)
开发最想要 17.9%(第3名) 14.6%(第5名)

2. 相似之处

Go和Rust有很多共同点。两者都是现代软件语言,都是出于为影响软件开发的问题提供一个安全和可扩展的解决方案的需要而诞生的。两者都是为了应对创建者在行业内现有语言中遇到的缺点而创建的,尤其是开发者生产力、可扩展性、安全性和并发性方面的缺点。

当今流行的大多数语言都是30多年前设计的。当这些语言被设计出来的时候,与今天有五个关键的区别:

  • 摩尔定律被认为是永恒不变的。
  • 大多数软件项目都是由小团队编写的,并且经常一个人单干。
  • 大多数软件有相对较少的依赖性,大多数是专有的。
  • 安全性是次要的考虑因素……或者根本不是考虑因素。
  • 软件通常是为单一平台编写的。

相比之下,Rust和Go都是为今天的世界而写的,并都采取了相似的方法来设计一种适合今天开发需求的语言。

1) 性能和并发

Go和Rust都是专注于生产高效代码的编译语言。它们还可以方便地使用当今机器的多个处理器,使它们成为编写高效并行代码的理想语言。

“使用Go使得MercadoLibre公司将他们用于这项服务的服务器数量减少到原来的八分之一(从32台服务器减少到4台),另外,每台服务器可以用更少的功率运行(原来是4个CPU核,现在减少到2个CPU核)。有了Go,该公司省去了88%的服务器,并将剩余服务器上的CPU削减了一半–产生了巨大的成本节约。”–“MercadoLibre与Go一起成长”

“在我们严格管理的环境中,在我们运行Go代码的环境中,我们看到CPU减少了大约百分之十[与C++相比],代码更干净,更可维护。” – Bala Natarajan,Paypal

“在AWS,我们也很喜欢Rust,因为它能帮助AWS编写高性能、安全的基础设施级网络和其他系统软件。亚马逊第一个用Rust构建的重要产品Firecracker于2018年公开发布,它提供了开源虚拟化技术,为AWS Lambda和其他无服务器产品提供动力。但我们也使用Rust来提供亚马逊简单存储服务(Amazon S3)、亚马逊弹性计算云(Amazon EC2)、Amazon CloudFront、Amazon Route 53等服务。最近,我们推出了基于Linux的容器操作系统Bottlerocket,它是用Rust编写的。” – Matt Asay,亚马逊网络服务

我们”看到我们的速度非凡地提高了1200-1500%! 我们从实现了较少解析规则的Scala的模式下的300-450ms,到实现了更多解析模式的Rust模式下的25-30ms!” – Josh Hannaford,IBM

2) 团队可扩展—-可审查

今天的软件开发是由团队建立的,这些团队不断成长和扩大,经常使用源码控制以分布式的方式进行协作。Go和Rust都是针对团队的工作方式而设计的,通过消除不必要的担忧,如格式(比如go的gofmt)、安全和复杂的组织,来改善代码审查。这两种语言都需要相对较少的上下文来理解代码的工作,使审查人员能够更快速地使用其他人编写的代码,并审查团队成员的代码和你团队以外的开源开发人员贡献的代码。

“我早期的职业生涯有Java和Ruby的背景,构建Go和Rust代码对我来说就像卸下了无法承受的重担。当我在Google时,遇到用Go编写的服务让我很欣慰,因为我知道它易于构建和运行。Rust的情况也是如此,尽管我只是在更小的工作范围内使用了它。我希望无限可配置的构建系统的日子已经过去了,而语言都有自己的专用构建工具,开箱即用。”– Sam Rose,CV合伙人

“用Go写服务的时候,我往往会松一口气,因为与动态语言相比,Go的静态类型系统非常简单,易于推理,并发性是一等公民,Go的标准库既无比精致强大,又切中要害。安装一个标准的Go,再使用一个grpc库和一个数据库连接器,你在服务器端几乎不需要其他的东西,每个工程师都能看懂代码,看懂库。在用Rust编写模块时,Dropbox工程师在2019年Async-await稳定下来之前,感受到了Rust在服务器端的成长之痛,但从那时起,crate(译注:Rust中的概念)正在趋向于使用它,我们得到了Async模式并从并发中受益。” – Daniel Reiter Horn,Dropbox

3) 开放源码意识

今天一般软件项目所使用的依赖关系数量是惊人的。长达几十年的软件重用目标在现代开发中已经实现,今天的软件可能是复用了100多个项目而构建的。为此,开发人员使用软件仓库,这越来越成为软件开发的主旋律,并在越来越广泛的领域应用。开发者所包含的每一个软件包,又有自己的依赖关系。为今天的编程环境而设计出的编程语言需要毫不费力地处理这种复杂性。

Go和Rust都有包管理系统,允许开发人员列出一个简单的清单,列出他们想要构建的包,语言工具就会自动为他们获取和维护这些包,这样开发人员就可以把更多的精力放在自己的代码上,而不是放在对其他包的管理上。

4) 安全性

Go和Rust都很好地解决了当今应用的安全问题,保证了用这些语言构建的代码在运行时不会让用户暴露在各种经典的安全漏洞中,比如缓冲区溢出、use-after-free(内存释放后还使用)等。通过消除这些顾虑,开发者可以专注于手头的问题,并在默认情况下构建更安全的应用程序。

“Rust编译器在解决您遇到的错误时确实能助您一臂之力。这样一来,您就可以专注于自己的业务目标,而不必寻找错误或解密隐秘消息。” -Josh Hannaford,IBM

简而言之,Rust的灵活性,安全性和安全性带给我们的益处超过了必须遵循严格的lifetime,borrow(rust中的概念)和其他编译器规则甚至缺乏垃圾收集器所带来的任何不便。这些功能是云软件项目中非常需要的功能,将有助于避免其中常见的许多错误。” —微软高级泰勒·托马斯(Taylor Thomas)

“Go是强静态类型化的,没有隐式转换,但语法开销还是小得惊人。这是通过赋值中简单的类型推理与非类型化的数值常量一起实现的。这使得Go比Java(有隐式转换)具有更强的类型安全性,但代码读起来更像Python(有非类型变量)。” – Stefan Nilsson,计算机科学教授

“当我们在Dropbox构建用于存储块数据的Brotli压缩库时,我们将自己限制在Rust的安全子集上,而且,也限制在核心库(no-stdlib)上,分配器指定为通用。这样使用Rust的子集,使得在客户端从Rust调用Rust-Brotli库,以及在服务器上使用Python和Go的C FFI变得非常容易。这种编译模式也提供了大量的安全保障。经过一些调整,Rust Brotli的实现尽管是100%安全的、经过数组边界检查的代码,但仍然比C语言中相应的原生Brotli代码快。” – Daniel Reiter Horn,Dropbox

5) 真正的可移植性

在Go和Rust中,写一个软件,在许多不同的操作系统和架构上运行是很容易的。”一次编写,随处编译”。此外,Go和Rust都原生支持交叉编译,消除了旧编译语言常见的”build farm”的需要。

“Go在生产优化方面拥有很好的特质,比如拥有较小的内存占用,这支持其在大型项目中被用于构建模块,以及开箱即用,易于交叉编译到其他架构。由于Go代码被编译成单一的静态二进制,我们可以轻松将其容器化,并且通过扩展,我们可以很轻松地将Go部署到任何高可用环境(如Kubernetes)中。” – Dewet Diener,Curve

“当你看一个基于云的基础设施时,通常你会使用类似Docker容器这样的东西来部署你的工作负载。通过在Go中构建的静态二进制,你可以拥有一个10、11、12兆字节的Docker文件,而不是带来整个Node.js生态系统,或像Python或Java那样动辄数百兆字节大小的Docker镜像文件。所以,交付那个微小的二进制文件是很神奇的。” – Brian Ketelsen,微软

“有了Rust,我们将拥有一个高性能和可移植的平台,我们可以轻松地在Mac、iOS、Linux、Android和Windows上运行。” – Matt Ronge,Astropad

3. 差异

在设计中,总是要做出一些取舍。虽然Go和Rust大约在同一时间出现,目标相似,但由于他们决策时选择了不同的取舍,使得这两种语言在关键的方面有所区别。

1) 性能方面

Go开箱即有出色的性能。在设计上,几乎没有预留任何旋钮或开关可以让你从Go中榨取更多的性能。Rust的设计是为了让您能够从代码中榨取每一滴性能;在这方面,您确实无法找到比Rust更快的语言。然而,Rust的性能提升是以额外的复杂性为代价的。

“值得注意的是,在编写Rust版本时,我们只在优化方面投入了非常基本的思考。即使只做了基本的优化,Rust的性能也能超过超手工调整的Go版本。这极大地证明了用Rust编写高效的程序是多么容易,相比之下,我们不得不对Go进行深挖。” – Jesse Howarth,Discord

“Dropbox工程师通过将行对行的Python代码移植到Go中,往往可以看到5倍的性能提升和延迟下降,与Python相比,内存使用率往往会大幅下降,因为没有GIL,进程数可能会减少。然而,当我们的内存受限时,比如在桌面客户端软件或某些服务器进程中,我们会转而使用Rust,因为Rust中的手动内存管理效率大大高于Go GC。” – Daniel Reiter Horn,Dropbox

2) 适应性/交互性

Go快速迭代的优势让开发人员可以快速尝试各种想法,并磨合出能解决手头任务的工作代码。通常情况下,这就足够了,可以让开发者腾出手来处理其他任务。另一方面,与Go相比,Rust的编译时间更长,导致迭代时间更慢。这就导致了Go在一些场景中能更好地工作,因为更快的周转时间能让开发人员适应不断变化的需求,而Rust则在一些场景中茁壮成长,因为在这些场景中,可以给予更多的时间来做出更精致、更高性能的实现。

“Go类型系统的天才之处在于调用者可以定义Interface,允许库返回仅需满足小接口但却支持扩展的结构。Rust类型系统的天才设计在于匹配语法与Result<>的结合,你可以静态地确定每一种可能性都会被处理,永远不必发明空值来满足未使用的返回参数。” – Daniel Reiter Horn,Dropbox

“(我)如果你的用例离客户更近,更容易受到需求变化的影响,那么用Go就会好很多,因为持续重构的成本要便宜很多。这就是你能多快地表达新的需求并尝试它们。” – Peter Bourgon,Fastly

3) 可学性

简单来说,真的没有比Go更“平易近人”的语言了。有很多团队能够在几周内采用Go并将Go服务/应用投入生产的故事。此外,Go在语言中是比较独特的,它的语言设计和实践在它10多年的生命中是相当一致的。所以,投入到学习Go上的时间可以保持很长一段时间的价值。相比之下,Rust由于其复杂性,被认为是一门难学的语言。一般来说,学习Rust需要几个月的时间才能感觉到自如,但这种额外的复杂性也带来了精确的控制和性能的提高。

“当时,没有一个团队成员知道Go,但在一个月内,每个人都在用Go写作”–Jaime Garcia,Capital One

“Go与其他编程语言不同的地方在于认知负担。你可以用更少的代码做更多的事情,这使得你更容易推理和理解你最终编写的代码。大多数Go代码最终看起来都很相似,所以,即使你在使用一个全新的代码库,你也可以很快上手并运行。” – Glen Balliet 美国运通忠诚度平台工程总监 美国运通使用Go进行支付和奖励

“然而,与其他编程语言不同,Go是为了最大限度地提高用户效率而创建的。因此,具有Java或PHP背景的开发人员和工程师可以在几周内获得使用Go的高级技能和培训–根据我们的经验,他们中的许多人最终都喜欢上了Go。” – Dewet Diener,Curve

4) 精确控制

也许Rust最大的优势之一就是开发者对如何管理内存、如何使用机器的可用资源、如何优化代码以及如何制作问题解决方案的控制。与Go相比,这并不是没有很大的复杂度成本,因为Go的设计并不是为了这种精确的制作,而是为了更快的探索时间和更快的周转时间。

“随着我们对Rust经验的增长,它在另外两个轴上显示出了优势:作为一种具有强大内存安全性的语言,它是边缘处理的好选择;作为一种具有巨大热情的语言,它成为了重写组件的流行语言。” – John Graham-Cumming,Cloudflare。

3. 总结/主要收获

Go的简单性、性能和开发人员的生产力使Go成为创建面向用户的应用程序和服务的理想语言。快速的迭代让团队能够快速地作出反应以满足用户不断变化的需求,让团队有办法将精力集中在灵活性上。

Rust更精细的控制允许更多的精确性,使得Rust成为低级操作的理想语言,这些低级操作不太可能发生变化,并且会从比Go略微提高的性能中受益,特别是在非常大的规模部署时。

Rust的优势在最接近“金属”(指底层机器)的地方。Go的优势是在离用户更近的地方最有利。这并不是说两者都不能在对方的空间里工作,但这样做会增加摩擦。当你的需求从灵活性转变为效率时,用Rust重写库的理由就更充分了。

虽然Go和Rust的设计有很大的不同,但它们的设计发挥了兼容的优势,而且–当一起使用时–既可以有很大的灵活性,又可以有很好的性能。

4. 我们的建议

对于大多数公司和用户来说,Go是正确的默认选择。它的性能很强,Go很容易采用,而且Go的高度模块化特性使它特别适合需求不断变化或发展的情况。

随着你的产品逐渐成熟,需求趋于稳定,可能会有机会从性能的边际增长中获得巨大的胜利。在这些情况下,使用Rust来最大限度地提高性能可能很值得你进行初始投资。


“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强。在2021年上半年,部落将策划两个专题系列分享,并且是部落独享哦:

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎各位Gopher加入!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订阅!目前该技术专栏正在新春促销!关注我的个人公众号“iamtonybai”,发送“go专栏活动”即可获取专栏专属优惠码,可在订阅专栏时抵扣20元哦(2021.2月末前有效)。

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

基于Redis Cluster的分布式锁实现以互斥方式操作共享资源

img{512x368}

今天要说的技术方案也是有一定项目背景的。在上一个项目中,我们需要对一个redis集群中过期的key进行处理,这是一个分布式
系统,考虑到高可用性,需要具备过期处理功能的服务有多个副本,这样我们就要求在同一时间内仅有一个副本可以对过期的key>进行处理,如果该副本挂掉,系统会在其他副本中再挑选出一个来处理过期的key。

很显然,这里涉及到一个选主(leader election)的过程。每当涉及选主,很多人就会想到一些高大上的分布式一致性/共识算法,
比如:raftpaxos等。当然使用这
些算法自然没有问题,但是也给系统徒增了很多复杂性。能否有一些更简单直接的方案呢?我们已经有了一个redis集群,是否可>以利用redis集群的能力来完成这一点呢?

Redis原生并没有提供leader election算法,但Redis作者提供了分布式锁的算法,也就>是说我们可以用分布式锁来实现一个简单的选主功能,见下图:

img{512x368}

图:利用redis分布式锁实现选主

在上图中我们看到,只有持有锁的服务才具备操作数据的资格,也就是说持有锁的服务的角色是leader,而其他服务则继续尝试去持有锁,它们是follower的角色。

1. 基于单节点redis的分布式锁

在redis官方有关分布式锁算法的介绍页面中,作者给出了各种编程语言的推荐实现,而Go语言的推荐实现仅redsync这一种。在这篇短文中,我们就来使用redsync实现基于Redis分布式锁的选主方案。

在Go生态中,连接和操作redis的主流go客户端库有go-redisredigo。最新的redsync版本底层redis driver既支持go-redis,也支持redigo,我个人日常使用最多的是go-redis这个客户端,这里我们就用go-redis。

redsync github主页中给出的例子是基于单redis node的分布式锁示例。下面我们也先以单redis节点来看看如何通过Redis的分布式锁实现我们的业务逻辑:

// github.com/bigwhite/experiments/blob/master/redis-cluster-distributed-lock/standalone/main.go

     1  package main
     2
     3  import (
     4      "context"
     5      "log"
     6      "os"
     7      "os/signal"
     8      "sync"
     9      "sync/atomic"
    10      "syscall"
    11      "time"
    12
    13      goredislib "github.com/go-redis/redis/v8"
    14      "github.com/go-redsync/redsync/v4"
    15      "github.com/go-redsync/redsync/v4/redis/goredis/v8"
    16  )
    17
    18  const (
    19      redisKeyExpiredEventSubj = `__keyevent@0__:expired`
    20  )
    21
    22  var (
    23      isLeader  int64
    24      m         atomic.Value
    25      id        string
    26      mutexName = "the-year-of-the-ox-2021"
    27  )
    28
    29  func init() {
    30      if len(os.Args) < 2 {
    31          panic("args number is not correct")
    32      }
    33      id = os.Args[1]
    34  }
    35
    36  func tryToBecomeLeader() (bool, func() (bool, error), error) {
    37      client := goredislib.NewClient(&goredislib.Options{
    38          Addr: "localhost:6379",
    39      })
    40      pool := goredis.NewPool(client)
    41      rs := redsync.New(pool)
    42
    43      mutex := rs.NewMutex(mutexName)
    44
    45      if err := mutex.Lock(); err != nil {
    46          client.Close()
    47          return false, nil, err
    48      }
    49
    50      return true, func() (bool, error) {
    51          return mutex.Unlock()
    52      }, nil
    53  }
    54
    55  func doElectionAndMaintainTheStatus(quit <-chan struct{}) {
    56      ticker := time.NewTicker(time.Second * 5)
    57      var err error
    58      var ok bool
    59      var cf func() (bool, error)
    60
    61      c := goredislib.NewClient(&goredislib.Options{
    62          Addr: "localhost:6379",
    63      })
    64      defer c.Close()
    65      for {
    66          select {
    67          case <-ticker.C:
    68              if atomic.LoadInt64(&isLeader) == 0 {
    69                  ok, cf, err = tryToBecomeLeader()
    70                  if ok {
    71                      log.Printf("prog-%s become leader successfully\n", id)
    72                      atomic.StoreInt64(&isLeader, 1)
    73                      defer cf()
    74                  }
    75                  if !ok || err != nil {
    76                      log.Printf("prog-%s try to become leader failed: %s\n", id, err)
    77                  }
    78              } else {
    79                  log.Printf("prog-%s is the leader\n", id)
    80                  // update the lock live time and maintain the leader status
    81                  c.Expire(context.Background(), mutexName, 8*time.Second)
    82              }
    83          case <-quit:
    84              return
    85          }
    86      }
    87  }
    88
    89  func doExpire(quit <-chan struct{}) {
    90      // subscribe the expire event of redis
    91      c := goredislib.NewClient(&goredislib.Options{
    92          Addr: "localhost:6379"})
    93      defer c.Close()
    94
    95      ctx := context.Background()
    96      pubsub := c.Subscribe(ctx, redisKeyExpiredEventSubj)
    97      _, err := pubsub.Receive(ctx)
    98      if err != nil {
    99          log.Printf("prog-%s subscribe expire event failed: %s\n", id, err)
   100          return
   101      }
   102      log.Printf("prog-%s subscribe expire event ok\n", id)
   103
   104      // Go channel which receives messages from redis db
   105      ch := pubsub.Channel()
   106      for {
   107          select {
   108          case event := <-ch:
   109              key := event.Payload
   110              if atomic.LoadInt64(&isLeader) == 0 {
   111                  break
   112              }
   113              log.Printf("prog-%s 收到并处理一条过期消息[key:%s]", id, key)
   114          case <-quit:
   115              return
   116          }
   117      }
   118  }
   119
   120  func main() {
   121      var wg sync.WaitGroup
   122      wg.Add(2)
   123      var quit = make(chan struct{})
   124
   125      go func() {
   126          doElectionAndMaintainTheStatus(quit)
   127          wg.Done()
   128      }()
   129      go func() {
   130          doExpire(quit)
   131          wg.Done()
   132      }()
   133
   134      c := make(chan os.Signal, 1)
   135      signal.Notify(c, syscall.SIGINT, syscall.SIGTERM)
   136      _ = <-c
   137      close(quit)
   138      log.Printf("recv exit signal...")
   139      wg.Wait()
   140      log.Printf("program exit ok")
   141  }

上面示例代码比较长,但它很完整。我们一点点来看。

首先,我们看120~141行的main函数结构。在这个函数中,我们创建了两个新goroutine,main goroutine通过sync.WaitGroup等待这两个子goroutine的退出并使用quit channel模式(关于goroutine的并发模式的详解,可以参考我的专栏文章《Go并发模型和常见并发模式》)在收到系统信号(关于signal包的使用,请参见我的专栏文章《小心被kill!不要忽略对系统信号的处理》)后通知两个子goroutine退出。

接下来,我们逐个看两个子goroutine的执行逻辑。第一个goroutine执行的是doElectionAndMaintainTheStatus函数。该函数会持续尝试去持有分布式锁(tryToBecomeLeader),一旦持有,它就变成了分布式系统中的leader角色;成为leader角色的副本会保持其角色状态(见81行)。

尝试持有分布式锁并成为leader是tryToBecomeLeader函数的主要职责,该函数直接使用了redsync包的算法,并利用与redis node建立的连接(NewClient),尝试建立并持有分布式锁“the-year-of-the-ox-2021”。我们使用的是默认的锁属性,从redsync包的NewMutex方法源码,我们能看到锁默认属性如下:

// github.com/go-redsync/redsync/redsync.go

// NewMutex returns a new distributed mutex with given name.
func (r *Redsync) NewMutex(name string, options ...Option) *Mutex {
        m := &Mutex{
                name:         name,
                expiry:       8 * time.Second,
                tries:        32,
                delayFunc:    func(tries int) time.Duration { return 500 * time.Millisecond },
                genValueFunc: genValue,
                factor:       0.01,
                quorum:       len(r.pools)/2 + 1,
                pools:        r.pools,
        }
        for _, o := range options {
                o.Apply(m)
        }
        return m
}

我们看到锁有一个过期时间属性(expiry),过期时间默认仅有8秒。问题来了:一旦锁过期了,那么情况会怎样?事实是一旦锁过期掉,在leader尚未解锁时,其follower也会加锁成功,因为原锁的key已经因过期而被删除掉了。长此以往,整个分布式系统就会存在多个自视为leader的进程,整个处理逻辑就乱了!

解决这个问题至少可以有三种方案:

  • 方案1:将锁的expiry设置的很长,长到一旦某个服务持有了锁,不需担心锁过期的问题;
  • 方案2:在所的默认expiry到期之前解锁,所有服务重新竞争锁;
  • 方案3:一旦某个服务持有了锁,则需要定期重设锁的expiry时间,保证锁不会过期,直到该服务主动执行unlock。

方案1的问题在于,一旦持有锁的leader因意外异常退出并且尚未unlock,那么由于锁的过期时间超级长,其他follower依然无法持有锁而变成下一任leader,导致整个分布式系统的leader缺失,业务逻辑无法继续进行;

方案2其实是基于Redis分布式锁的常规使用方式,但对于像我这里的业务场景,频繁lock和unlock没必要,我只需要保证系统中有一个leader一直在处理过期event即可,在服务间轮流处理并非我的需求。但这个方案是一个可行的方案,代码逻辑清晰也简单。

方案3则是非常适合我的业务场景的方案,持有锁的leader通过定期(<8s)的更新锁的过期时间来保证锁的有效性,这样避免了leader频繁切换。这里我们就使用了这一方案,见78~82行,我们在定时器的帮助下,定期重新设置了锁的过期时间(8s)。

在上述示例代码中,我们用一个变量isLeader来标识该服务是否持有了锁,由于该变量被多个goroutine访问和修改,因此我们通过atomic包实现对其的原子访问以避免出现race问题。

最后,我们说说这段示例承载的业务逻辑(doExpire函数)。真正的业务逻辑由doExpire函数实现。它通过监听redis 0号库的key空间的过期事件实现对目标key的过期处理(这里并未体现这一点)。

subscribe的subject字符串为keyevent@0:expired,这个字符串的组成含义可以参考redis官方对notifications的说明,这里的字串表明我们要监听key事件,在0号数据库,事件类型是key过期。

当在0号数据库有key过期后,我们的订阅channel(105行)就会收到一个事件,通过event的Payload我们可以得到key的名称,后续我们可以根据key的名字来过滤掉我们不关心的key,而仅对期望的key做相应处理。

在默认配置下, redis的通知功能处于关闭状态。我们需要通过命令或在redis.conf中开启这一功能。

$redis-cli
127.0.0.1:6379> config set notify-keyspace-events KEx
OK

到这里,我们已经搞清楚了上面示例代码的原理,下面我们就来真实运行一次上面的代码,我们编译上面代码并启动三个实例:

$go build main.go
$./main 1
$./main 2
$./main 3

由于./main 1先启动,因此第一个启动的服务一般会先成为leader:

$main 1
2021/02/11 05:43:15 prog-1 subscribe expire event ok
2021/02/11 05:43:20 prog-1 become leader successfully
2021/02/11 05:43:25 prog-1 is the leader
2021/02/11 05:43:30 prog-1 is the leader

而其他两个服务会定期尝试去持有锁:

$main 2
2021/02/11 05:43:17 prog-2 subscribe expire event ok
2021/02/11 05:43:37 prog-2 try to become leader failed: redsync: failed to acquire lock
2021/02/11 05:43:53 prog-2 try to become leader failed: redsync: failed to acquire lock

$main 3
2021/02/11 05:43:18 prog-3 subscribe expire event ok
2021/02/11 05:43:38 prog-3 try to become leader failed: redsync: failed to acquire lock
2021/02/11 05:43:54 prog-3 try to become leader failed: redsync: failed to acquire lock

这时我们通过redis-cli在0号数据库中创建一个key1,过期时间5s:

$redis-cli
127.0.0.1:6379> setex key1 5 value1
OK

5s后,我们会在prog-1这个服务实例的输出日志中看到如下内容:

2021/02/11 05:43:50 prog-1 is the leader
2021/02/11 05:43:53 prog-1 收到并处理一条过期消息[key:key1]
2021/02/11 05:43:55 prog-1 is the leader

接下来,我们停掉prog-1:

2021/02/11 05:44:00 prog-1 is the leader
^C2021/02/11 05:44:01 recv exit signal...
redis: 2021/02/11 05:44:01 pubsub.go:168: redis: discarding bad PubSub connection: read tcp [::1]:56594->[::1]:6379: use of closed network connection
2021/02/11 05:44:01 program exit ok

在停掉prog-1后的瞬间,prog-2成功持有了锁,并成为leader:

2021/02/11 05:44:01 prog-2 become leader successfully
2021/02/11 05:44:01 prog-2 is the leader

我们再通过redis-cli在0号数据库中创建一个key2,过期时间5s:

$redis-cli
127.0.0.1:6379> setex key2 5 value2
OK

5s后,我们会在prog-2这个服务实例的输出日志中看到如下内容:

2021/02/11 05:44:17 prog-2 is the leader
2021/02/11 05:44:19 prog-2 收到并处理一条过期消息[key:key2]
2021/02/11 05:44:22 prog-2 is the leader

从运行的结果来看,该分布式系统的运行逻辑是符合我们的设计预期的。

2. 基于redis集群的分布式锁

上面,我们实现了基于单个redis节点的分布式锁的选主功能。在生产环境,我们很少会使用单节点的Redis,通常会使用Redis集群以保证高可用性。

最新的redsync已经支持了redis cluster(基于go-redis)。和单节点唯一不同的是,我们传递给redsync的pool所使用的与redis的连接由Client类型变为了ClusterClient类型:

// github.com/bigwhite/experiments/blob/master/redis-cluster-distributed-lock/cluster/v1/main.go
const (
        redisClusterMasters      = "localhost:30001,localhost:30002,localhost:30003"
)

func main() {
    ... ...
        client := goredislib.NewClusterClient(&goredislib.ClusterOptions{
                Addrs: strings.Split(redisClusterMasters, ",")})
        defer client.Close()
    ... ...
}

我们在本地启动的redis cluster,三个master的地址分别为:localhost:30001、localhost:30002和localhost:30003。我们将master的地址组成一个逗号分隔的常量redisClusterMasters。

我们对上面单节点的代码做了改进,将Redis连接的创建放在了main中,并将client连接作为参数传递给各个goroutine的运行函数。下面是cluster版示例代码完整版(v1):

// github.com/bigwhite/experiments/blob/master/redis-cluster-distributed-lock/cluster/v1/main.go

     1  package main
     2
     3  import (
     4      "context"
     5      "log"
     6      "os"
     7      "os/signal"
     8      "strings"
     9      "sync"
    10      "sync/atomic"
    11      "syscall"
    12      "time"
    13
    14      goredislib "github.com/go-redis/redis/v8"
    15      "github.com/go-redsync/redsync/v4"
    16      "github.com/go-redsync/redsync/v4/redis/goredis/v8"
    17  )
    18
    19  const (
    20      redisKeyExpiredEventSubj = `__keyevent@0__:expired`
    21      redisClusterMasters      = "localhost:30001,localhost:30002,localhost:30003"
    22  )
    23
    24  var (
    25      isLeader  int64
    26      m         atomic.Value
    27      id        string
    28      mutexName = "the-year-of-the-ox-2021"
    29  )
    30
    31  func init() {
    32      if len(os.Args) < 2 {
    33          panic("args number is not correct")
    34      }
    35      id = os.Args[1]
    36  }
    37
    38  func tryToBecomeLeader(client *goredislib.ClusterClient) (bool, func() (bool, error), error) {
    39      pool := goredis.NewPool(client)
    40      rs := redsync.New(pool)
    41
    42      mutex := rs.NewMutex(mutexName)
    43
    44      if err := mutex.Lock(); err != nil {
    45          return false, nil, err
    46      }
    47
    48      return true, func() (bool, error) {
    49          return mutex.Unlock()
    50      }, nil
    51  }
    52
    53  func doElectionAndMaintainTheStatus(c *goredislib.ClusterClient, quit <-chan struct{}) {
    54      ticker := time.NewTicker(time.Second * 5)
    55      var err error
    56      var ok bool
    57      var cf func() (bool, error)
    58
    59      for {
    60          select {
    61          case <-ticker.C:
    62              if atomic.LoadInt64(&isLeader) == 0 {
    63                  ok, cf, err = tryToBecomeLeader(c)
    64                  if ok {
    65                      log.Printf("prog-%s become leader successfully\n", id)
    66                      atomic.StoreInt64(&isLeader, 1)
    67                      defer cf()
    68                  }
    69                  if !ok || err != nil {
    70                      log.Printf("prog-%s try to become leader failed: %s\n", id, err)
    71                  }
    72              } else {
    73                  log.Printf("prog-%s is the leader\n", id)
    74                  // update the lock live time and maintain the leader status
    75                  c.Expire(context.Background(), mutexName, 8*time.Second)
    76              }
    77          case <-quit:
    78              return
    79          }
    80      }
    81  }
    82
    83  func doExpire(c *goredislib.ClusterClient, quit <-chan struct{}) {
    84      // subscribe the expire event of redis
    85      ctx := context.Background()
    86      pubsub := c.Subscribe(ctx, redisKeyExpiredEventSubj)
    87      _, err := pubsub.Receive(ctx)
    88      if err != nil {
    89          log.Printf("prog-%s subscribe expire event failed: %s\n", id, err)
    90          return
    91      }
    92      log.Printf("prog-%s subscribe expire event ok\n", id)
    93
    94      // Go channel which receives messages from redis db
    95      ch := pubsub.Channel()
    96      for {
    97          select {
    98          case event := <-ch:
    99              key := event.Payload
   100              if atomic.LoadInt64(&isLeader) == 0 {
   101                  break
   102              }
   103              log.Printf("prog-%s 收到并处理一条过期消息[key:%s]", id, key)
   104          case <-quit:
   105              return
   106          }
   107      }
   108  }
   109
   110  func main() {
   111      var wg sync.WaitGroup
   112      wg.Add(2)
   113      var quit = make(chan struct{})
   114      client := goredislib.NewClusterClient(&goredislib.ClusterOptions{
   115          Addrs: strings.Split(redisClusterMasters, ",")})
   116      defer client.Close()
   117
   118      go func() {
   119          doElectionAndMaintainTheStatus(client, quit)
   120          wg.Done()
   121      }()
   122      go func() {
   123          doExpire(client, quit)
   124          wg.Done()
   125      }()
   126
   127      c := make(chan os.Signal, 1)
   128      signal.Notify(c, syscall.SIGINT, syscall.SIGTERM)
   129      _ = <-c
   130      close(quit)
   131      log.Printf("recv exit signal...")
   132      wg.Wait()
   133      log.Printf("program exit ok")
   134  }

和单一节点一样,我们运行三个服务实例:

$go build main.go
$main 1
2021/02/11 09:49:16 prog-1 subscribe expire event ok
2021/02/11 09:49:22 prog-1 become leader successfully
2021/02/11 09:49:26 prog-1 is the leader
2021/02/11 09:49:31 prog-1 is the leader
2021/02/11 09:49:36 prog-1 is the leader
... ...

$main 2
2021/02/11 09:49:19 prog-2 subscribe expire event ok
2021/02/11 09:49:40 prog-2 try to become leader failed: redsync: failed to acquire lock
2021/02/11 09:49:55 prog-2 try to become leader failed: redsync: failed to acquire lock
... ...

$main 3
2021/02/11 09:49:31 prog-3 subscribe expire event ok
2021/02/11 09:49:52 prog-3 try to become leader failed: redsync: failed to acquire lock
2021/02/11 09:50:07 prog-3 try to become leader failed: redsync: failed to acquire lock
... ...

我们看到基于Redis集群版的分布式锁也生效了!prog-1成功持有锁并成为leader! 接下来我们再来看看对过期key事件的处理!

我们通过下面命令让redis-cli连接到集群中的所有节点并设置每个节点开启key空间的事件通知:

三主:

$redis-cli -c -h localhost -p 30001
localhost:30001> config set notify-keyspace-events KEx
OK

$redis-cli -c -h localhost -p 30002
localhost:30002> config set notify-keyspace-events KEx
OK

$redis-cli -c -h localhost -p 30003
localhost:30003> config set notify-keyspace-events KEx
OK

三从:

$redis-cli -c -h localhost -p 30004
localhost:30004> config set notify-keyspace-events KEx
OK

$redis-cli -c -h localhost -p 30005
localhost:30005> config set notify-keyspace-events KEx
OK

$redis-cli -c -h localhost -p 30006
localhost:30006> config set notify-keyspace-events KEx
OK

在node1节点上,我们set一个有效期为5s的key:key1:

localhost:30001> setex key1 5 value1
-> Redirected to slot [9189] located at 127.0.0.1:30002
OK

等待5s后,我们的leader:prog-1并没有如预期那样受到expire通知! 这是怎么回事呢?追本溯源,我们查看一下redis官方文档关于notifications的说明,我们在文档最后一段找到如下描述:

Events in a cluster

Every node of a Redis cluster generates events about its own subset of the keyspace as described above. However, unlike regular Pub/Sub communication in a cluster, events' notifications are not broadcasted to all nodes. Put differently, keyspace events are node-specific. This means that to receive all keyspace events of a cluster, clients need to subscribe to each of the nodes.

这段话大致意思是Redis集群中的每个redis node都有自己的keyspace,事件通知不会被广播到集群内的所有节点,即keyspace的事件是node相关的。如果要接收一个集群中的所有keyspace的event,那客户端就需要Subcribe集群内的所有节点。我们来改一下代码,形成v2版(考虑到篇幅就不列出所有代码了,仅列出相对于v1版变化的代码):

// github.com/bigwhite/experiments/blob/master/redis-cluster-distributed-lock/cluster/v2/main.go

... ...
    19  const (
    20      redisKeyExpiredEventSubj = `__keyevent@0__:expired`
    21      redisClusterMasters      = "localhost:30001,localhost:30002,localhost:30003,localhost:30004,localhost:30005,localhost:30006"
    22  )
... ...
    83  func doExpire(quit <-chan struct{}) {
    84      var ch = make(chan *goredislib.Message)
    85      nodes := strings.Split(redisClusterMasters, ",")
    86
    87      for _, node := range nodes {
    88          node := node
    89          go func(quit <-chan struct{}) {
    90              c := goredislib.NewClient(&goredislib.Options{
    91                  Addr: node})
    92              defer c.Close()
    93
    94              // subscribe the expire event of redis
    95              ctx := context.Background()
    96              pubsub := c.Subscribe(ctx, redisKeyExpiredEventSubj)
    97              _, err := pubsub.Receive(ctx)
    98              if err != nil {
    99                  log.Printf("prog-%s subscribe expire event of node[%s] failed: %s\n",
   100                      id, node, err)
   101                  return
   102              }
   103              log.Printf("prog-%s subscribe expire event of node[%s] ok\n", id, node)
   104
   105              // Go channel which receives messages from redis db
   106              pch := pubsub.Channel()
   107
   108              for {
   109                  select {
   110                  case event := <-pch:
   111                      ch <- event
   112                  case <-quit:
   113                      return
   114                  }
   115              }
   116          }(quit)
   117      }
   118      for {
   119          select {
   120          case event := <-ch:
   121              key := event.Payload
   122              if atomic.LoadInt64(&isLeader) == 0 {
   123                  break
   124              }
   125              log.Printf("prog-%s 收到并处理一条过期消息[key:%s]", id, key)
   126          case <-quit:
   127              return
   128          }
   129      }
   130  }
   131
   132  func main() {
   133      var wg sync.WaitGroup
   134      wg.Add(2)
   135      var quit = make(chan struct{})
   136      client := goredislib.NewClusterClient(&goredislib.ClusterOptions{
   137          Addrs: strings.Split(redisClusterMasters, ",")})
   138      defer client.Close()
   139
   140      go func() {
   141          doElectionAndMaintainTheStatus(client, quit)
   142          wg.Done()
   143      }()
   144      go func() {
   145          doExpire(quit)
   146          wg.Done()
   147      }()
   148
   149      c := make(chan os.Signal, 1)
   150      signal.Notify(c, syscall.SIGINT, syscall.SIGTERM)
   151      _ = <-c
   152      close(quit)
   153      log.Printf("recv exit signal...")
   154      wg.Wait()
   155      log.Printf("program exit ok")
   156  }

在这个新版代码中,我们在每个新goroutine中实现对redis一个节点的Subscribe,并将收到的Event notifications通过“扇入”模式(更多关于并发扇入模式的内容,可以参考我的Go技术专栏文章《Go并发模型和常见并发模式》)统一写入到运行doExpire的goroutine中做统一处理。

我们再来运行一下这个示例,并在不同时机创建多个key来验证通知接收和处理的效果:

$main 1
2021/02/11 10:29:21 prog-1 subscribe expire event of node[localhost:30004] ok
2021/02/11 10:29:21 prog-1 subscribe expire event of node[localhost:30001] ok
2021/02/11 10:29:21 prog-1 subscribe expire event of node[localhost:30006] ok
2021/02/11 10:29:21 prog-1 subscribe expire event of node[localhost:30002] ok
2021/02/11 10:29:21 prog-1 subscribe expire event of node[localhost:30003] ok
2021/02/11 10:29:21 prog-1 subscribe expire event of node[localhost:30005] ok
2021/02/11 10:29:26 prog-1 become leader successfully
2021/02/11 10:29:31 prog-1 is the leader
2021/02/11 10:29:36 prog-1 is the leader
2021/02/11 10:29:41 prog-1 is the leader
2021/02/11 10:29:46 prog-1 is the leader
2021/02/11 10:29:47 prog-1 收到并处理一条过期消息[key:key1]
2021/02/11 10:29:51 prog-1 is the leader
2021/02/11 10:29:51 prog-1 收到并处理一条过期消息[key:key2]
2021/02/11 10:29:56 prog-1 收到并处理一条过期消息[key:key3]
2021/02/11 10:29:56 prog-1 is the leader
2021/02/11 10:30:01 prog-1 is the leader
2021/02/11 10:30:06 prog-1 is the leader
^C2021/02/11 10:30:08 recv exit signal...

$main 3
2021/02/11 10:29:27 prog-3 subscribe expire event of node[localhost:30004] ok
2021/02/11 10:29:27 prog-3 subscribe expire event of node[localhost:30006] ok
2021/02/11 10:29:27 prog-3 subscribe expire event of node[localhost:30002] ok
2021/02/11 10:29:27 prog-3 subscribe expire event of node[localhost:30001] ok
2021/02/11 10:29:27 prog-3 subscribe expire event of node[localhost:30005] ok
2021/02/11 10:29:27 prog-3 subscribe expire event of node[localhost:30003] ok
2021/02/11 10:29:48 prog-3 try to become leader failed: redsync: failed to acquire lock
2021/02/11 10:30:03 prog-3 try to become leader failed: redsync: failed to acquire lock
2021/02/11 10:30:08 prog-3 become leader successfully
2021/02/11 10:30:08 prog-3 is the leader
2021/02/11 10:30:12 prog-3 is the leader
2021/02/11 10:30:17 prog-3 is the leader
2021/02/11 10:30:22 prog-3 is the leader
2021/02/11 10:30:23 prog-3 收到并处理一条过期消息[key:key4]
2021/02/11 10:30:27 prog-3 is the leader
^C2021/02/11 10:30:28 recv exit signal...

$main 2
2021/02/11 10:29:24 prog-2 subscribe expire event of node[localhost:30005] ok
2021/02/11 10:29:24 prog-2 subscribe expire event of node[localhost:30006] ok
2021/02/11 10:29:24 prog-2 subscribe expire event of node[localhost:30003] ok
2021/02/11 10:29:24 prog-2 subscribe expire event of node[localhost:30004] ok
2021/02/11 10:29:24 prog-2 subscribe expire event of node[localhost:30002] ok
2021/02/11 10:29:24 prog-2 subscribe expire event of node[localhost:30001] ok
2021/02/11 10:29:45 prog-2 try to become leader failed: redsync: failed to acquire lock
2021/02/11 10:30:01 prog-2 try to become leader failed: redsync: failed to acquire lock
2021/02/11 10:30:16 prog-2 try to become leader failed: redsync: failed to acquire lock
2021/02/11 10:30:28 prog-2 become leader successfully
2021/02/11 10:30:28 prog-2 is the leader
2021/02/11 10:30:29 prog-2 is the leader
2021/02/11 10:30:34 prog-2 is the leader
2021/02/11 10:30:39 prog-2 收到并处理一条过期消息[key:key5]
2021/02/11 10:30:39 prog-2 is the leader
^C2021/02/11 10:30:41 recv exit signal...

这个运行结果如预期!

不过这个方案显然也不是那么理想,毕竟我们要单独Subscribe每个集群内的redis节点,目前没有理想方案,除非redis cluster支持带广播的Event notification。

以上示例代码可以在这里 https://github.com/bigwhite/experiments/tree/master/redis-cluster-distributed-lock 下载 。


“Gopher部落”知识星球开球了!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!星球首开,福利自然是少不了的!2020年年底之前,8.8折(很吉利吧^_^)加入星球,下方图片扫起来吧!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订阅!

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats