Go 语言中的动态 JSON

Python010

Go 语言中的动态 JSON,第1张

Go 语言是静态类型语言,虽然它也可以表现出动态类型,但是使用一个嵌套的 map[string]interface{} 在那里乱叫会让代码变得特别丑。通过掌握语言的静态特性,我们可以做的更好。

通过同一通道交换多种信息的时候,我们经常需要 JSON 具有动态的,或者更合适的参数内容。首先,让我们来讨论一下消息封装(message envelopes),JSON 在这里看起来就像这样:

通过 interface{},我们可以很容易的将数据结构编码成为独立封装的,具有多种类型的消息体的 JSON 数据。为了生成下面的 JSON :

我们可以使用这些 Go 类型:

输出的结果是:

这些并没有什么特殊的。

如果你想将上面的 JSON 对象解析成为一个 Envelope 类型的对象,最终你会将 Msg 字段解析成为一个 map[string]interface{}。 这种方式不是很好用,会使你后悔你的选择。

输出:

就像前面说的,我推荐修改 Envelope 类型,就像这样:

json.RawMessage 非常有用,它可以让你延迟解析相应的 JSON 数据。它会将未处理的数据存储为 []byte。

这种方式可以让你显式控制 Msg 的解析。从而延迟到获取到 Type 的值之后,依据 Type 的值进行解析。这种方式不好的地方在于你需要先明确解析 Msg,或者你需要单独分为 EnvelopeIn 和 EnvelopeOut 两种类型,其中 EnvelopeOut 仍然有 Msg interface{}。

那么如何将上述两者好的一面结合起来呢?通过在 interface{} 字段中放入 *json.RawMessage!

输出:

虽然我极其推荐你将动态可变的部分放在一个单独的 key 下面,但是有时你可能需要处理一些预先存在的数据,它们并没有用这样的方式进行格式化。

如果可以的话,请使用文章前面提到的风格。

我们可以通过解析两次数据的方式来解决。

dynamite

编写过C语言程序的肯定知道通过malloc()方法动态申请内存,其中内存分配器使用的是glibc提供的ptmalloc2。 除了glibc,业界比较出名的内存分配器有Google的tcmalloc和Facebook的jemalloc。二者在避免内存碎片和性能上均比glic有比较大的优势,在多线程环境中效果更明显。

Golang中也实现了内存分配器,原理与tcmalloc类似,简单的说就是维护一块大的全局内存,每个线程(Golang中为P)维护一块小的私有内存,私有内存不足再从全局申请。另外,内存分配与GC(垃圾回收)关系密切,所以了解GC前有必要了解内存分配的原理。

为了方便自主管理内存,做法便是先向系统申请一块内存,然后将内存切割成小块,通过一定的内存分配算法管理内存。 以64位系统为例,Golang程序启动时会向系统申请的内存如下图所示:

预申请的内存划分为spans、bitmap、arena三部分。其中arena即为所谓的堆区,应用中需要的内存从这里分配。其中spans和bitmap是为了管理arena区而存在的。

arena的大小为512G,为了方便管理把arena区域划分成一个个的page,每个page为8KB,一共有512GB/8KB个页;

spans区域存放span的指针,每个指针对应一个page,所以span区域的大小为(512GB/8KB)乘以指针大小8byte = 512M

bitmap区域大小也是通过arena计算出来,不过主要用于GC。

span是用于管理arena页的关键数据结构,每个span中包含1个或多个连续页,为了满足小对象分配,span中的一页会划分更小的粒度,而对于大对象比如超过页大小,则通过多页实现。

根据对象大小,划分了一系列class,每个class都代表一个固定大小的对象,以及每个span的大小。如下表所示:

上表中每列含义如下:

class: class ID,每个span结构中都有一个class ID, 表示该span可处理的对象类型

bytes/obj:该class代表对象的字节数

bytes/span:每个span占用堆的字节数,也即页数乘以页大小

objects: 每个span可分配的对象个数,也即(bytes/spans)/(bytes/obj)waste

bytes: 每个span产生的内存碎片,也即(bytes/spans)%(bytes/obj)上表可见最大的对象是32K大小,超过32K大小的由特殊的class表示,该class ID为0,每个class只包含一个对象。

span是内存管理的基本单位,每个span用于管理特定的class对象, 跟据对象大小,span将一个或多个页拆分成多个块进行管理。src/runtime/mheap.go:mspan定义了其数据结构:

以class 10为例,span和管理的内存如下图所示:

spanclass为10,参照class表可得出npages=1,nelems=56,elemsize为144。其中startAddr是在span初始化时就指定了某个页的地址。allocBits指向一个位图,每位代表一个块是否被分配,本例中有两个块已经被分配,其allocCount也为2。next和prev用于将多个span链接起来,这有利于管理多个span,接下来会进行说明。

有了管理内存的基本单位span,还要有个数据结构来管理span,这个数据结构叫mcentral,各线程需要内存时从mcentral管理的span中申请内存,为了避免多线程申请内存时不断的加锁,Golang为每个线程分配了span的缓存,这个缓存即是cache。src/runtime/mcache.go:mcache定义了cache的数据结构

alloc为mspan的指针数组,数组大小为class总数的2倍。数组中每个元素代表了一种class类型的span列表,每种class类型都有两组span列表,第一组列表中所表示的对象中包含了指针,第二组列表中所表示的对象不含有指针,这么做是为了提高GC扫描性能,对于不包含指针的span列表,没必要去扫描。根据对象是否包含指针,将对象分为noscan和scan两类,其中noscan代表没有指针,而scan则代表有指针,需要GC进行扫描。mcache和span的对应关系如下图所示:

mchache在初始化时是没有任何span的,在使用过程中会动态的从central中获取并缓存下来,跟据使用情况,每种class的span个数也不相同。上图所示,class 0的span数比class1的要多,说明本线程中分配的小对象要多一些。

cache作为线程的私有资源为单个线程服务,而central则是全局资源,为多个线程服务,当某个线程内存不足时会向central申请,当某个线程释放内存时又会回收进central。src/runtime/mcentral.go:mcentral定义了central数据结构:

lock: 线程间互斥锁,防止多线程读写冲突

spanclass : 每个mcentral管理着一组有相同class的span列表

nonempty: 指还有内存可用的span列表

empty: 指没有内存可用的span列表

nmalloc: 指累计分配的对象个数线程从central获取span步骤如下:

将span归还步骤如下:

从mcentral数据结构可见,每个mcentral对象只管理特定的class规格的span。事实上每种class都会对应一个mcentral,这个mcentral的集合存放于mheap数据结构中。src/runtime/mheap.go:mheap定义了heap的数据结构:

lock: 互斥锁

spans: 指向spans区域,用于映射span和page的关系

bitmap:bitmap的起始地址

arena_start: arena区域首地址

arena_used: 当前arena已使用区域的最大地址

central: 每种class对应的两个mcentral

从数据结构可见,mheap管理着全部的内存,事实上Golang就是通过一个mheap类型的全局变量进行内存管理的。mheap内存管理示意图如下:

系统预分配的内存分为spans、bitmap、arean三个区域,通过mheap管理起来。接下来看内存分配过程。

针对待分配对象的大小不同有不同的分配逻辑:

(0, 16B) 且不包含指针的对象: Tiny分配

(0, 16B) 包含指针的对象:正常分配

[16B, 32KB] : 正常分配

(32KB, -) : 大对象分配其中Tiny分配和大对象分配都属于内存管理的优化范畴,这里暂时仅关注一般的分配方法。

以申请size为n的内存为例,分配步骤如下:

Golang内存分配是个相当复杂的过程,其中还掺杂了GC的处理,这里仅仅对其关键数据结构进行了说明,了解其原理而又不至于深陷实现细节。1、Golang程序启动时申请一大块内存并划分成spans、bitmap、arena区域

2、arena区域按页划分成一个个小块。

3、span管理一个或多个页。

4、mcentral管理多个span供线程申请使用

5、mcache作为线程私有资源,资源来源于mcentral。

三次握手:

            1. 主动发起连接请求端(客户端),发送 SYN 标志位,携带数据包、包号

            2. 被动接收连接请求端(服务器),接收 SYN,回复 ACK,携带应答序列号。同时,发送SYN标志位,携带数据包、包号

            3. 主动发起连接请求端(客户端),接收SYN 标志位,回复 ACK。

                        被动端(服务器)接收 ACK —— 标志着 三次握手建立完成( Accept()/Dial() 返回 )

四次挥手:

            1. 主动请求断开连接端(客户端), 发送 FIN标志,携带数据包

            2. 被动接受断开连接端(服务器), 发送 ACK标志,携带应答序列号。 —— 半关闭完成。

            3. 被动接受断开连接端(服务器), 发送 FIN标志,携带数据包

            4. 主动请求断开连接端(客户端), 发送 最后一个 ACK标志,携带应答序列号。—— 发送完成,客户端不会直接退出,等 2MSL时长。

                        等 2MSL待目的:确保服务器 收到最后一个ACK

滑动窗口:

            通知对端本地存储数据的 缓冲区容量。—— write 函数在对端 缓冲区满时,有可能阻塞。

TCP状态转换:

            1. 主动发起连接请求端:

                        CLOSED ——>发送SYN ——>SYN_SENT(了解) ——>接收ACK、SYN,回发 ACK ——>ESTABLISHED (数据通信)

            2. 主动关闭连接请求端:

                        ESTABLISHED ——>发送FIN ——>FIN_WAIT_1 ——>接收ACK ——>FIN_WAIT_2 (半关闭、主动端)

                        ——>接收FIN、回复ACK ——>TIME_WAIT (主动端) ——>等 2MSL 时长 ——>CLOSED

            3. 被动建立连接请求端:

                        CLOSED ——>LISTEN ——>接收SYN、发送ACK、SYN ——>SYN_RCVD ——>接收 ACK ——>ESTABLISHED (数据通信)

            4. 被动断开连接请求端:

                        ESTABLISHED ——>接收 FIN、发送 ACK ——>CLOSE_WAIT ——>发送 FIN ——>LAST_ACK ——>接收ACK ——>CLOSED

windows下查看TCP状态转换:

            netstat -an | findstr  端口号

Linux下查看TCP状态转换:

            netstat -an | grep  端口号

TCP和UDP对比: 

            TCP: 面向连接的可靠的数据包传递。 针对不稳定的 网络层,完全弥补。ACK

            UDP:无连接不可靠的报文传输。 针对不稳定的 网络层,完全不弥补。还原网络真实状态。

                                    优点                                                            缺点

            TCP: 可靠、顺序、稳定                                      系统资源消耗大,程序实现繁复、速度慢

            UDP:系统资源消耗小,程序实现简单、速度快                          不可靠、无序、不稳定

使用场景:

            TCP:大文件、可靠数据传输。 对数据的 稳定性、准确性、一致性要求较高的场合。

            UDP:应用于对数据时效性要求较高的场合。 网络直播、电话会议、视频直播、网络游戏。

UDP-CS-Server实现流程:

            1.  创建 udp地址结构 ResolveUDPAddr(“协议”, “IP:port”) ——>udpAddr 本质 struct{IP、port}

            2.  创建用于 数据通信的 socket ListenUDP(“协议”, udpAddr ) ——>udpConn (socket)

            3.  从客户端读取数据,获取对端的地址 udpConn.ReadFromUDP() ——>返回:n,clientAddr, err

            4.  发送数据包给 客户端 udpConn.WriteToUDP("数据", clientAddr)

UDP-CS-Client实现流程:

            1.  创建用于通信的 socket。 net.Dial("udp", "服务器IP:port") ——>udpConn (socket)

            2.  以后流程参见 TCP客户端实现源码。

UDPserver默认就支持并发!

------------------------------------

命令行参数: 在main函数启动时,向整个程序传参。 【重点】

            语法: go run xxx.go   argv1 argv2  argv3  argv4 。。。

                        xxx.exe:  第 0 个参数。

                        argv1 :第 1 个参数。

                        argv2 :第 2 个参数。

                        argv3 :第 3 个参数。

                        argv4 :第 4 个参数。

            使用: list := os.Args  提取所有命令行参数。

获取文件属性函数:

            os.stat(文件访问绝对路径) ——>fileInfo 接口

            fileInfo 包含 两个接口。

                        Name() 获取文件名。 不带访问路径

                        Size() 获取文件大小。

网络文件传输 —— 发送端(客户端)

            1.  获取命令行参数,得到文件名(带路径)filePath list := os.Args

            2.  使用 os.stat() 获取 文件名(不带路径)fileName

            3.  创建 用于数据传输的 socket  net.Dial("tcp", “服务器IP+port”) —— conn

            4.  发送文件名(不带路径)  给接收端, conn.write()

            5.  读取 接收端回发“ok”,判断无误。封装函数 sendFile(filePath, conn) 发送文件内容

            6.  实现 sendFile(filePath,  conn)

                        1) 只读打开文件 os.Open(filePath)

                                    for {

                                    2) 从文件中读数据  f.Read(buf)

                                    3) 将读到的数据写到socket中  conn.write(buf[:n])

                                    4)判断读取文件的 结尾。 io.EOF. 跳出循环

                                    }

网络文件传输 —— 接收端(服务器)

            1. 创建用于监听的 socket net.Listen() —— listener

            2. 借助listener 创建用于 通信的 socket listener.Accpet()  —— conn

            3. 读取 conn.read() 发送端的 文件名, 保存至本地。

            4. 回发 “ok”应答 发送端。

            5. 封装函数,接收文件内容 recvFile(文件路径)

                        1) f = os.Create(带有路径的文件名)

                        for {

                        2)从 socket中读取发送端发送的 文件内容 。 conn.read(buf)

                        3)  将读到的数据 保存至本地文件 f.Write(buf[:n])

                        4)  判断 读取conn 结束, 代表文件传输完成。 n == 0  break

                        }