[]T 还是 []*T, 这是一个问题

在编程语言深入讨论中,经常被大家提起也是争论最多的讨论之一就是按值(by value)还是按引用传递(by reference, by pointer),你可以在C/C++或者Java的社区经常看到这样的讨论,也会看到很多这样的面试题。

对于Go语言,严格意义上来讲,只有一种传递,也就是按值传递(by value)。当一个变量当作参数传递的时候,会创建一个变量的副本,然后传递给函数或者方法,你可以看到这个副本的地址和变量的地址是不一样的。

当变量当做指针被传递的时候,一个新的指针被创建,它指向变量指向的同样的内存地址,所以你可以将这个指针看成原始变量指针的副本。当这样理解的时候,我们就可以理解成Go总是创建一个副本按值转递,只不过这个副本有时候是变量的副本,有时候是变量指针的副本。

这是Go语言中你理解后续问题的基础。

但是Go语言的情况比较复杂,我们什么时候选择 T 作为参数类型,什么时候选择 *T作为参数类型? []T是传递的指针还是值?选择[]T还是[]*T? 哪些类型复制和传递的时候会创建副本?什么情况下会发生副本创建?

本文将详细介绍Go语言的变量的副本创建还是变量指针的副本创建的case以及各种类型在这些case的情况。

阅读全文

一个有特色的有限状态机

gofsm是一个简单、小巧而又特色的有限状态机(FSM)。

github已经有了很几个状态机的实现,比如下面的几个,还为什么要再发明轮子呢?

原因在于这些状态机有一个特点,就是一个状态机维护一个对象的状态,这样一个状态机就和一个具体的图像实例关联在一起,在有些情况下,这没有什么问题,而且是很好的设计,而且比较符合状态机的定义。但是在有些情况下,当我们需要维护成千上百个对象的时候,需要创建成千上百个状态机对象,这其实是很大的浪费,因为在大部分情况下,对象本身自己会维护/保持自己当前的状态,我们只需把对象当前的状态传递给一个共用的状态机就可以了,也就是gofsm本身是“stateless”,本身它包维护一个或者多个对象的状态,所有需要的输入由调用者输入,它只负责状态的转换的逻辑,所以它的实现非常的简洁实用,这是创建gofsm的一个目的。

第二个原因它提供了Moore和Mealy两种状态机的统一接口,并且提供了UML状态机风格的Action处理,以程序员更熟悉的方式处理状态的改变。

第三个原因,当我们谈论起状态机的时候,我们总会画一个状态转换图,大家可以根据这这张图进行讨论、设计、实现和验证状态的迁移。但是对于代码来说,实现真的和你的设计是一致的吗,你怎么保证?gofsm提供了一个简单的方法,那就是它可以输出图片或者pdf文件,你可以利用输出的状态机图和你的设计进行比较,看看实现和设计是否一致。

gofsm生成的闸门状态图

阅读全文

调试利器:dump goroutine 的 stacktrace

Stack trace是指堆栈回溯信息,在当前时间,以当前方法的执行点开始,回溯调用它的方法的方法的执行点,然后继续回溯,这样就可以跟踪整个方法的调用,大家比较熟悉的是JDK所带的jstack工具,可以把Java的所有线程的stack trace都打印出来。

它有什么用呢?用处非常的大,当应用出现一些状况的时候,比如某个模块不执行, 锁竞争、CPU占用非常高等问题, 又没有足够的log信息可以分析,那么可以查看stack trace信息,看看线程都被阻塞或者运行在那些代码上,然后定位问题所在。

对于Go开发的程序,有没有类似jstack这样的利器呢,目前我还没有看到,但是我们可以通过其它途径也很方便的输出goroutine的stack trace信息。

本文介绍了几种方法,尤其是最后介绍的方法比较有用。

阅读全文

使用算法检测英超中的食物链

最近看到一篇新闻: 英超再现恐怖食物链!20强相生相克 今年用了14轮,对于足球和英超感兴趣的读者一定了解,所谓食物链是指A队胜过B队,B队胜过C队,……,N队也胜过A队,截止到英超第14轮,根据所有的队伍的胜负关系,一条最大的食物链已经形成,英超20队都加入到这个食物链中,相生相克。

我看到这篇新闻的时候,有一点点程序员的不由自主的想法,能否通过算法检查目前最大的食物链,以及能否将食物链罗列出来?这也算是算法解决实际问题的一个很好的例子吧。

阅读全文

平滑的基于权重的轮询算法

轮询算法是非常常用的一种调度/负载均衡的算法。依照百度百科上的解释:

Round-Robin,轮询调度,通信中信道调度的一种策略,该调度策略使用户轮流使用共享资源,不会考虑瞬时信道条件。从相同数量无线资源(相同调度时间段)被分配给每条通信链路的角度讲,轮询调度可以被视为公平调度。然而,从提供相同服务质量给所有通信链路的角度而言,轮询调度是不公平的,此时,必须为带有较差信道条件的通信链路分配更多无线资源(更多时间)。此外,由于轮询调度在调度过程中不考虑瞬时信道条件,因此它将导致较低的整体系统性能,但与最大载干比调度相比,在各通信链路间具有更为均衡的服务质量。

更广泛的轮询调度应用在广度的服务调度上面,尤其在面向服务或者是面向微服务的架构中,比可以在很多知名的软件中看到它的身影,比如LVS、Nginx、Dubblo等。但是正如上面的百度百科中的介绍一样,轮询调度有一个很大的问题,那就是它认为所有的服务的性能都是一样的,每个服务器都被公平的调度,在服务器的性能有显著差别的环境中,性能比较差的服务器被调度了相同的次数,这不是我们所期望的。所以本文要介绍的是加权的轮询算法,轮询算法可以看成是加权的轮询算法的一个特例,在这种情况下,每个服务器的权重都是一样的。

本文介绍了Nginx和LVS的两种算法,比较了它们的优缺点,并提供了一个通用的 Go 语言实现的加权轮询算法库: weighted,可以用在负载均衡/调度/微服务网关等场合。

阅读全文

微服务的反模式和陷阱

前几天我写了篇读书笔记: 《产品级微服务的八大原则》,介绍了Uber的SRE工程师 Susan J. Fowler 的免费书: Microservices in Production,文中提出了一个微服务成功与否的唯一标准就是可用性,非常有实践意义。但是这本书偏向于从 SRE (site reliability engineer)的视角看待微服务,对于开发工程师 (SWE, software engineer)来说,更关注的是如何正确地从单体程序重构到微服务架构,或者从头设计微服务架构, 这篇读书笔记主要就是介绍这方面的实践和经验。

Oreilly 的 的这本免费小书 Microservices AntiPatterns and Pitfalls由经验丰富的 Mark Richards 编写。书中将反模式(AntiPattern)定义为"起初看起来很美好,做到最后麻烦不断的实践模式",而将陷阱(Pitfall)定义为“起初看起来就不是一个好的设计”,书中列举了微服务开发中几种常见的反模式和陷阱,这些经验非常的接地气.他还提供了视频教程

阅读全文

优雅地实现 TCP 压缩传输

集群式、负载均衡的RPC框架 rpcx支持多种的序列化库,可以有效的减少消息体的大小,但是对于字符串或者图片的字节slice,明显还可以进一步的压缩,正如fasthttp作者valyala在他的新的开源项目httpteleport中描述的: 通过1G的带宽传输10G的数据 (夸张)。

为了在RPC的传输中减少传输的数据大小,我在不影响rpcx整体框架的基础上,参考了httpteleport的实现,对net.TCPConn进行了封装,实现了压缩/解压缩功能的net.Conn,可以有效的减少带宽,节省公司在带宽上的花费, 以下就是具体的实现。

阅读全文

Go的函数参数总是传值

依照Go的FQA, 函数的参数传递总是传值的(pass-by-value):

As in all languages in the C family, everything in Go is passed by value. That is, a function always gets a copy of the thing being passed, as if there were an assignment statement assigning the value to the parameter. For instance, passing an int value to a function makes a copy of the int, and passing a pointer value makes a copy of the pointer, but not the data it points to. (See a later section for a discussion of how this affects method receivers.)

Map and slice values behave like pointers: they are descriptors that contain pointers to the underlying map or slice data. Copying a map or slice value doesn't copy the data it points to. Copying an interface value makes a copy of the thing stored in the interface value. If the interface value holds a struct, copying the interface value makes a copy of the struct. If the interface value holds a pointer, copying the interface value makes a copy of the pointer, but again not the data it points to.

阅读全文

深入Go UDP编程

用户数据报协议(User Datagram Protocol,缩写为UDP),又称用户数据报文协议,是一个简单的面向数据报(package-oriented)的传输层协议,正式规范为RFC 768。UDP只提供数据的不可靠传递,它一旦把应用程序发给网络层的数据发送出去,就不保留数据备份(所以UDP有时候也被认为是不可靠的数据报协议)。UDP在IP数据报的头部仅仅加入了复用和数据校验。

由于缺乏可靠性且属于非连接导向协议,UDP应用一般必须允许一定量的丢包、出错和复制粘贴。但有些应用,比如TFTP,如果需要则必须在应用层增加根本的可靠机制。但是绝大多数UDP应用都不需要可靠机制,甚至可能因为引入可靠机制而降低性能。流媒体(流技术)、即时多媒体游戏和IP电话(VoIP)一定就是典型的UDP应用。如果某个应用需要很高的可靠性,那么可以用传输控制协议(TCP协议)来代替UDP。

由于缺乏拥塞控制(congestion control),需要基于网络的机制来减少因失控和高速UDP流量负荷而导致的拥塞崩溃效应。换句话说,因为UDP发送者不能够检测拥塞,所以像使用包队列和丢弃技术的路由器这样的网络基本设备往往就成为降低UDP过大通信量的有效工具。数据报拥塞控制协议(DCCP)设计成通过在诸如流媒体类型的高速率UDP流中,增加主机拥塞控制,来减小这个潜在的问题。
典型网络上的众多使用UDP协议的关键应用一定程度上是相似的。这些应用包括域名系统(DNS)、简单网络管理协议(SNMP)、动态主机配置协议(DHCP)、路由信息协议(RIP)和某些影音流服务等等。

UDP报头
偏移字节0123
字节 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
00来源连接端口目的连接端口
432报长检查码

IPv4伪头部

0 – 78 – 1516 – 2324 – 31
0来源地址
32目的地址
64全零协议名UDP报文长度
96来源连接端口目的连接端口
128报文长度检验和
160+ 
数据
 

IPv6伪头部

0 – 78 – 1516 – 2324 – 31
0来源地址
32
64
96
128目的地址
160
192
224
256UDP报文长
288全零下一个指针位置
320来源连接端口目的连接端口
352报文长校验和
384+ 
数据
 

以上大段的背景介绍引自维基百科。

而TCP是面向连接(connection-oriented)的协议,可以提供可靠的数据传输。

本文讲介绍Go语言的UDP库及其使用方法,以及了解使用过程中的细节和陷阱。

阅读全文