https://checkking.github.io/ Recent content on Check King's Blog Hugo -- gohugo.io © Check King 2018 Wed, 14 Nov 2018 21:39:13 +0800 https://checkking.github.io/post/http/https/ Wed, 14 Nov 2018 21:39:13 +0800 https://checkking.github.io/post/http/https/ https简单过程 客户端请求服务器拿到CA证书 客户端验证服务器下发的CA证书是否有合法(通过签名)，如果合法拿到非对称公钥 客户端随机生成对称密钥，并通过公钥加密发送给服务端 客户端和服务端通过对称密钥进行数据传输 为什么不直接用非对称密钥 性能 参考 https://www.cnblogs.com/svan/p/5090201.html https://checkking.github.io/post/redis/redis_ha/ Tue, 13 Nov 2018 22:42:40 +0800 https://checkking.github.io/post/redis/redis_ha/ 主从同步 为了避免单点故障，引入主从，提高可用性。当master挂掉，从库来接管。 * 增量同步：主节点将修改命令记录在本地的内存buffer中，然后异步将buffer中的指令同步到从节点。buffer是一个环形数组，如果内存满了，就会从头开始覆盖前面的内容。 * 快照同步：主库bgsave内存数据到磁盘，从库接收完毕，继续增量同步。 * 新的从节点加入，必须先执行一次快照同步，然后再继续进行增量同步。 * 无盘复制 leader 选举 redis leader选举有一个方案是sentinel，当主节点挂掉时，自动选择一个最优的从节点切换为主节点。 客户端连接集群时，首先连接sentinel, 通过sentinel来查询主节点地址，然后再去连接主节点进行数据交互。 Sentinel无法保证消息完全不丢失，但可以尽量保证少丢失。它有两个选项可以限制主从延迟过大。 min-slaves-to-write 1 min-slaves-max-lag 10 redis分片 redis分片一个非官方的方案是Codis Codis分片是通过槽位来管理的，每个槽位记录hash对应到redis client的映射关系。 不同codis实例之间的槽位关系通过zookeeper或etcd来支持的。 redis增加实例后，会引起codis槽位迁移, 当迁移过程中，有请求的key落在这个槽位上，先强制迁移这个槽位，再访问key。 由于槽位迁移会用到getall操作，如果存在大key，会引起服务卡顿，因此不建议大key（不超过1M）。 redis cluster 待补充 https://checkking.github.io/post/redis/redis_persistence/ Tue, 13 Nov 2018 16:56:14 +0800 https://checkking.github.io/post/redis/redis_persistence/ 持久化 redis持久化包括rdb, aof, rdb是快照的全量备份的方式，aof是增量备份的方式, aof 可以采用aof重写使其进行紧凑。 redis rdb 采用cow技术，保证父进程同时也允许写操作。 https://checkking.github.io/post/redis/redis_data_stracture/ Tue, 13 Nov 2018 14:18:15 +0800 https://checkking.github.io/post/redis/redis_data_stracture/ 字符串 redis字符串是一个二进制安全的，并自带有长度信息。字符串叫做「SDS」，也就是Simple Dynamic String. struct SDS<T> { T capacity; // 数组容量 T len; // 数组长度 byte flags; // 特殊标识位，不理睬它 byte[] content; // 数组内容 } 当字符串长度很短时，使用embstr的格式，当长度超过44字节时，使用raw形式存储。raw形式字符串内容与RedisObject对象的不是在一个连续的内存空间中。 字典 dict有两个hasttable,通常情况下只有一个hashtable有值，但在dict扩容缩容时，要分配新的hashtable。 渐进式rehash: 当redis处于rehash进程中，redis的增删修改等操作都会触发rehash小步搬迁,并且redis还会在定时任务中对词典进行主动搬迁。 压缩列表 zset和hash容器对象在元素个数较少的时候，采用压缩列表(ziplist)进行存储。 当set集合容纳的元素都是整数并且元素个数较小时，Redis会使用intset来存储结合元素。 快速列表 redis为了节省普通列表因pre,next指针所带来的内存开销和碎片化，采用快速列表的来实现列表。 quicklist时ziplist和linkedlist的混合体，它将linkedlist按段切分，每一段使用ziplist来紧凑存储，多个ziplist之间使用双向指针串接起来。 struct ziplist { ... } struct ziplist_compressed { int32 size; byte[] compressed_data; } struct quicklistNode { quicklistNode* prev; quicklistNode* next; ziplist* zl; // 指向压缩列表 int32 size; // ziplist 的字节总数 int16 count; // ziplist 中的元素数量 int2 encoding; // 存储形式 2bit，原生字节数组还是 LZF 压缩存储 . https://checkking.github.io/post/arch/kafka/ Tue, 13 Nov 2018 10:21:04 +0800 https://checkking.github.io/post/arch/kafka/ Kafka整体架构 一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。 Topic & Partition & consumer group Topic在逻辑上可认为是一个队列，每条消息都必须制定它的Topic，也就是指明放在哪个队列上。为了提高Kafka的吞吐率，物理上把Topic分成一个或多个partition，每个Partition在物理上是一个文件夹，包含这个partition的所有消息，以及消息的索引, 消息存储在日志文件中，消息格式如下： 　message length ： 4 bytes (value: 1+4+n) "magic" value ： 1 byte crc ： 4 bytes payload ： n bytes 这个log entry并非由一个文件构成，而是分成多个segment，每个segment以该segment第一条消息的offset命名并以“.kafka”为后缀。另外会有一个索引文件，它标明了每个segment下包含的log entry的offset范围，如下图所示。 每条消息都被append到该Partition中，属于顺序写磁盘，因此效率非常高. 每个partition的消息能够保序, 消息全局不保序。 同一Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。 kafka的消费者消费消息是采用pull模式。 Kafka会为每一个Consumer Group保留一些metadata信息——当前消费的消息的position，也即offset。这个offset由Consumer控制。 Kafka HA kafka 为了避免broker宕机引起的不可用问题，引入Replication来保证高可用。 为了解决引入replica所带来的消息复制效率问题，引入leader来解决这个问题，保证leader写成功，并且确保isr都写入成功。 leader选主通过类似PacificA算法。 注：后续需要详细研究一下。 https://checkking.github.io/post/go_under_the_hook/interface/ Mon, 05 Nov 2018 21:00:56 +0800 https://checkking.github.io/post/go_under_the_hook/interface/ 引入 func Foo(x interface{}) { if x == nil { fmt.Println("empty interface") return } fmt.Println("non-empty interface") } func main() { var x *int = nil Foo(x) } 上面的例子的输出结果如下 $ go run test_interface.go non-empty interface interface底层结构 根据 interface 是否包含有 method，底层实现上用两种 struct 来表示：iface 和 eface。eface表示不含 method 的 interface 结构，或者叫 empty interface。对于 Golang 中的大部分数据类型都可以抽象出来 _type 结构，同时针对不同的类型还会有一些其他信息。 type eface struct { _type *_type data unsafe.Pointer } type _type struct { size uintptr // type size ptrdata uintptr // size of memory prefix holding all pointers hash uint32 // hash of type; avoids computation in hash tables tflag tflag // extra type information flags align uint8 // alignment of variable with this type fieldalign uint8 // alignment of struct field with this type kind uint8 // enumeration for C alg *typeAlg // algorithm table gcdata *byte // garbage collection data str nameOff // string form ptrToThis typeOff // type for pointer to this type, may be zero } iface 表示 non-empty interface 的底层实现。相比于 empty interface，non-empty 要包含一些 method。method 的具体实现存放在 itab. https://checkking.github.io/post/go_under_the_hook/array_and_slice/ Mon, 05 Nov 2018 18:28:59 +0800 https://checkking.github.io/post/go_under_the_hook/array_and_slice/ 数组和slice长的很像，操作方式也都差不多，并且slice包含了数组的基本的操作方式，如下标、range循环，还有一些如len()则是多种类型共用，所以根据操作根本搞不清数组和切片的区别，能够看出区别的地方主要看如何声明的。 数组 数组的声明方式很单一，通常是下面的样子： a := [5]int{1:10, 2:20} Go语言的数组是一个值，Go语言中的数组是值类型，一个数组变量就表示着整个数组，意味着Go语言的数组在传递的时候，传递的是原数组的拷贝。 slice 切片是一个很小的对象，是对数组进行了抽象，并提供相关的操作方法。切片有三个属性字段：长度、容量和指向数组的指针。其声明方式比较多: var slice1 = []int{1, 2, 3, 4, 5} var slice2 = make([]int, 0, 5) var slice3 = make([]int, 5, 5) var slice4 = make([]int, 5) 其中make(t type, len int, cap int), len表示make之后返回的slice的length，cap是容量。slice2和slice3是不一样的，slice2的内容为[], 而slice3的内容为[0, 0, 0, 0, 0] 扩容 slice这种数据结构便于使用和管理数据集合，可以理解为是一种“动态数组”，slice也是围绕动态数组的概念来构建的。既然是动态数组，那么slice是如何扩容的呢？ 请记住以下两条规则： 如果切片的容量小于1024个元素，那么扩容的时候slice的cap就翻番，乘以2；一旦元素个数超过1024个元素，增长因子就变成1.25，即每次增加原来容量的四分之一。 如果扩容之后，还没有触及原数组的容量，那么，切片中的指针指向的位置，就还是原数组，如果扩容之后，超过了原数组的容量，那么，Go就会开辟一块新的内存，把原来的值拷贝过来，这种情况丝毫不会影响到原数组。 https://checkking.github.io/post/go_under_the_hook/init/ Mon, 05 Nov 2018 16:03:25 +0800 https://checkking.github.io/post/go_under_the_hook/init/ 一个例子 package main import ( "fmt" ) func init() { a := "xxx" fmt.Printf("hello, %s, %s", "world!", a) } func main() { fmt.Println("main...") } 编译之后执行：go tool objdump -s "main.init" main。可以看到 TEXT main.init.0(SB) /Users/chenkang/learn/go/go_under_the_hook/03/main1.go ... main1.go:9 0x108f25a e801caf7ff CALL runtime.convT2Estring(SB) ... main1.go:9 0x108f2f2 e89981ffff CALL fmt.Printf(SB) ... main1.go:7 0x108f30e e83dc3fbff CALL runtime.morestack_noctxt(SB) main1.go:7 0x108f313 e998feffff JMP main.init.0(SB) ... TEXT main.init(SB) <autogenerated> ... <autogenerated>:1 0x108f3fe e89d56f9ff CALL runtime.throwinit(SB) ... <autogenerated>:1 0x108f40c e84ffbffff CALL fmt. https://checkking.github.io/post/arch/websocket/ Mon, 05 Nov 2018 13:46:09 +0800 https://checkking.github.io/post/arch/websocket/ 概述 WebSocket协议被设计来取代现有的使用HTTP作为传输层的双向通信技术，并受益于现有的基础设施（代理、过滤、身份验证）。协议有两部分：握手和数据传输。 来自客户端的握手看起来像如下形式： GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 重点请求首部意义如下： * Connection: Upgrade：表示要升级协议 * Upgrade: websocket：表示要升级到 websocket 协议。 * Sec-WebSocket-Version: 13：表示 websocket 的版本。如果服务端不支持该版本，需要返回一个 Sec-WebSocket-Versionheader ，里面包含服务端支持的版本号。 * Sec-WebSocket-Key：与后面服务端响应首部的 Sec-WebSocket-Accept 是配套的，提供基本的防护，比如恶意的连接，或者无意的连接。 来自服务器的握手看起来像如下形式： HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat Sec-WebSocket-Accept 根据客户端请求首部的 Sec-WebSocket-Key 计算出来。 计算公式为： toBase64(sha1(Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11)) 一旦客户端和服务器都发送了它们的握手，且如果握手成功，接着开始数据传输部分。 这是一个每一端都可以的双向通信信道，彼此独立，随意发生数据。 https://checkking.github.io/post/arch/frontier/ Sun, 04 Nov 2018 21:45:17 +0800 https://checkking.github.io/post/arch/frontier/ 背景 目前项目中用到了公司的长链接服务，抽空研究了一下公司长链接服务源码。 如果没有长链接服务，一些消息推送等功能只能用短链接轮询，或者长链接轮询的方式。长链接能够很好的解决短轮询和长轮询的一些不足。 整体架构 !架构图 数据流交互 !数据流交互 客户端传送fpid, aid, device_id, access_key等参数与grontier建立websocket连接， websocket 的subprotocol为pbbp2。 grontier维护webscoket连接池, 维护在内存中。 grontier向backbone注册映射, backbone将注册关系存入redis中。 客户端发送业务消息到grontier，grontier根据路由service, method参数进行路由调用backservice, backservice处理业务逻辑，将下行消息通过调用backbone接口返回，backbone将下行消息返回给grontier, 最终由grontier 返回给客户端。 源码分析 grontier/main.go 主要是启动两个server, 一个是thrift server, 一个是websocket server， 端口不一样。 其中thrift server对是用于与backbone和backservice交互的, websocket server是与客户端交互的。 rontier/thrift.go grontierThriftServer主要有3个函数，一个Start, 一个Close和handle。 Start是启动一个tcp监听端口，等待连接，如果有链接请求来了，则起一个协程调用handle处理这个链接。 handle 函数首先创建一个grontierServerhandler h，然后调用h.Serve，并传入BufferReader r, BufferWriter w。 在grontierServerHandler中，Serve函数循环从r中读取数据包，首先读取MessageHeader，包括messageType (int32)，name(string)，seq(int32)。其中name目前支持”PushByUUID” , messageType只支持CALL 。 读取正确的messageHeader后读取参数grontierPushByUUIDArgs。 读取完整的请求后，向request channel 塞入一条记录。 Serve函数还启动了一个协程，遍历channel 中的请求(request)， 调用grontierHandler的PushByUUID函数，也就是调用grontierClient的PushByUUID接口（是业务应用调用grontier对外提供的接口吗？还是backbone调用grontier?） Close是关闭tcp链接， 是在服务被shutdown的时候调用的。 grontier/grontier.go grontierWebsocketServer的结构体定义如下： type grontierWebsocketServer struct { mu sync.Mutex listeners []net. https://checkking.github.io/post/lang/go1/ Thu, 25 Oct 2018 19:35:11 +0800 https://checkking.github.io/post/lang/go1/ 背景 项目中遇到一个小问题，我用到一个库，但是这个库在异常情况下内部会panic，虽然可以在最外层的函数recover住，让服务继续运行，但业务上需要如果这个库panic了，能够做一些逻辑处理，也就是类似java等语言的try…cache操作。 方案 新加一个函数对库函数进行包装，然后recover住panic，并且调用的地方能够感知到出错了。打算在将recover返回的error信息返回给调用函数。因此做了如下改造： func (r *Request) ReplyRunOnceDataV2(statuscode int, contentType string, data []byte) (err interface{}) { defer func() { err = recover() }() r.ReplyRunOnceData(statuscode, contentType, data) return } 注意，这里函数返回值定义了一个有名返回值，是基于如下golang基础知识： 1. 多个defer的执行顺序为“后进先出”； 2. 所有函数在执行RET返回指令之前，都会先检查是否存在defer语句，若存在则先逆序调用defer语句进行收尾工作再退出返回； 3. 匿名返回值是在return执行时被声明，有名返回值则是在函数声明的同时被声明，因此在defer语句中只能访问有名返回值，而不能直接访问匿名返回值； 4. return其实应该包含前后两个步骤：第一步是给返回值赋值（若为有名返回值则直接赋值，若为匿名返回值则先声明再赋值）；第二步是调用RET返回指令并传入返回值，而RET则会检查defer是否存在，若存在就先逆序插播defer语句，最后RET携带返回值退出函数； 因此，‍‍defer、return、返回值三者的执行顺序应该是：return最先给返回值赋值；接着defer开始执行一些收尾工作；最后RET指令携带返回值退出函数。 匿名返回值的情况 package main import ( "fmt" ) func main() { fmt.Println("a return:", a()) // 打印结果为 a return: 0 } func a() int { var i int defer func() { i++ fmt. https://checkking.github.io/post/arch/cas/ Sun, 21 Oct 2018 18:47:24 +0800 https://checkking.github.io/post/arch/cas/ 问题描述 最近项目遇到这样一个问题，有一个用mysql数据库表模拟的任务队列，生产者会往表中增加任务，消费者采用轮询的方式去获取任务。其中新加入的任务的状态为NEW(1)，当任务被拿走并处于计算中的状态为PENDING(2)，当任务处理成功的状态为SUCCESS(0)，当任务被处理失败的状态为FAILED(3)。消费者从轮询数据库，如果有NEW状态的任务，拿到任务，则修改状态为PENDING。问题是，有多个消费者同时去查询数据库表，并更新表项，存在并发问题。 初步解决 对于数据库并发问题，一个直觉的做法就是采用加锁的办法，因此采用下面这种方式实现: tx := db.Begin() tx = tx.Raw("SELECT * FROM parser_job WHERE id=? FOR UPDATE", job.Id).Scan(&job) if tx.RecordNotFound() { tx.Rollback() return nil, nil } if tx.Error != nil { logs.Errorf("DequeJob db query failed, err:%s", tx.Error.Error()) tx.Rollback() return nil, errors.New(tx.Error.Error()) } columns := make(map[string]interface{}, 0) columns["status"] = common.STATUS_PENDING err := tx.Exec("UPDATE parser_job SET status=? WHERE id=?", common.STATUS_PENDING, job.Id).Error if err != nil { logs.Errorf("DequeJob db update failed, err:%s", err. https://checkking.github.io/about/ Wed, 03 Oct 2018 21:07:16 +0800 https://checkking.github.io/about/ 几年前在百度云上部署了一个博客，后来由于没有按时续费被关闭了。自己维护一个博客还是有点麻烦，因此打算在将博客迁移到github上。 关于我 大龄码农 Backend (C/C++ golang python) Email: Y2hlY2traW5nQGZveG1haWwuY29t https://checkking.github.io/post/nginx/nginx8/ Fri, 20 Oct 2017 21:07:16 +0800 https://checkking.github.io/post/nginx/nginx8/ 一个典型的nginx.conf配置 worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent $request_id "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; server { listen 80; server_name www.domain.com; root /root/com/domain/www; index index.html index.htm index.php; location ~ \.(jpg|png|gif|js|css|swf|flv|ico)$ { expires 12h; } #charset koi8-r; access_log logs/host.access.log main; error_log logs/host.error.log debug; location / { if (! https://checkking.github.io/post/lang/cpp4/ Sat, 13 May 2017 21:07:16 +0800 https://checkking.github.io/post/lang/cpp4/ 通常析构函数中会做一些内存、资源的释放操作，如果析构函数抛出异常，则在异常点之后的一些释放操作就不能执行了，导致资源泄露. 可能会导致连续抛出异常，程序由于某种原因抛出异常，而异常导致析构函数的调用，析构函数如果再抛出异常，一个异常没有处理，又来一个，会造成程序崩溃的问题。 参考：《more effective C++》 https://checkking.github.io/post/lang/cpp5/ Sat, 13 May 2017 21:07:16 +0800 https://checkking.github.io/post/lang/cpp5/ 避免使用原始指针，最佳实践是shared_ptr和weak_ptr的结合。因为原始指针容易造成空悬指针/野指针(因为在一个线程里调用一个对象，这个对象可能在其他的线程里被销毁了)， shared_ptr通过引用计数的方式保证有线程引用对象的时候，对象不会被销毁，weak_ptr的引入可以避免shared_ptr带来的延长对象生命周期的问题。 用enable_shared_ptr可以避免回调函数注册时传入的对象指针this，在回调的时候变成野指针（boost::bind传入this作为当前对象，但是在回调的时候，this可能被销毁了） 前台线程读(多个，高并发), 后台线程写（少量，低频） 可以用互斥锁来解决这个问题， shared_ptr存放Map，shared_ptr.swap()实现copy on write class CustomerData : boost::noncopyable { public: CustomerData() : _data(new Map) { } int query(const string& customer, const string& stock) const { MapPtr data = getData(); Map::const_iterator entries = data->find(customer); if (entries != data->end()) { return findEntry(entries->second, stock); } else { return -1; } } void update(const string& customer, const EntryList& entries) { MutexLockGuard lock(_mutex); if (! https://checkking.github.io/post/arch/rate_limitator/ Mon, 01 May 2017 21:07:16 +0800 https://checkking.github.io/post/arch/rate_limitator/ 背景 公有云的服务通常是将私有云的服务进行包装，并对外提供服务的，由于业务应用系统的负载能力有限，为了防止非预期的请求对系统压力过大而拖垮业务应用系统，需要对请求流量进行限速。 漏斗算法 漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。 优点 可以让流量匀速通过，实现简单 缺点 流量始终匀速输出，对于突发特性的流量支持地不好 实现 用一个队列即可搞定，消费者线程匀速取出 令牌桶算法 令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法,更加容易理解.随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了.新请求来临时,会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务. 优点 可以应对突发性的流量 缺点 实现起来不是很容易 实现 下面详细 通过redis实现令牌桶算法进行流量控制 流量控制项目 单个Ip访问速度限制 规则: reqs / seconds， 例如: 300 / 60, 表示每分钟最多允许300个请求，也就是平均每秒钟5个请求，但是我们可以允许流量的抖动，允许每5秒内有100个请求，这时，我们可以这样设定： 100 / 5, 两个规则加在一起就能满足两个要求了。 具体流程： 一个请求过来，对于每个规则构造key: key = GLOBAL_PREFIX_FOR_REDIS + PREFIX_RATE_LIMIT + KEY_SPLIT_FLAG + request.getClientIp() + i; 判断redis中key对应的列表长度, 如果列表长度小于限制，则通过; 如果大于等于限制，首先判断最早加入列表的元素（time）时间和当前时间差是否大于perSecond， 如果是，则将最早的时间元素从redis中移除，并将当前时间元素加入redis，允许请求通过，而且标记上后续清理过期的时间项目。如果不允许通过，则抛出异常 // 统计是否封禁 for (int i = 0; maxRateLimitPerIps ! https://checkking.github.io/post/arch/sample/ Sun, 30 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/arch/sample/ 背景 对于一些重要的产品，开发出的新功能往往需要真实流量进行验证才能知道这个功能带来的收益是好还是坏，比如图搜变现的策略rd想要在图搜wise端出游戏的一个广告banner，点击这个广告banner，会跳到一个下载中间页，我们最终的目的是要提高下载量，这就要评估一下哪种下载中间页会提高下载量，当然还有一些其他的评估指标。因此需要从整个流量中抽取两个小部分流量来做对比实验。怎么去分配流量，让不同流量走不同的逻辑就是抽样框架的主要任务。 还有FE开发了一种新的广告样式，需要确认这种样式会不会提高CTR。这些新策略，新样式的上线，都需要灰度发布，也就是小流量实验。 我们的广告模块也实现了一个实验框架，用于灰度发布，我分析一下这个实验框架的细节。 实验框架的整体流程 实验用户通过抽样平台上创建抽样试验，比如这个抽样试验要对流量按照uid进行划分，实验组需要流量为1%, 对照组所需流量为1%，如果现有所有流量层有按照cuid划分的，并且这一层上剩余流量充足，则在这一层上选取流量区间分配给实验组和对照组。 则可以将流量区间1000~1099分配给实验组，并创建一个新的sid加入配置，将1100~1199分配给对照组，并创建一个新的sid加入配置。 流量分配好之后，就可以在这个流量下面创建一些策略变量，比如在实验组中这个变量值为x,在对照组中，这个变量值为y（变量需要指定模块）。还可以加入一些过滤条件，对流量进行过滤。比如比如query不能在某个此表中。 实验创建好，并通过审核，准备上线。就会生成两类配置。一类是广告入口模块（midway）所使用的流量划分配置，模块根据这个配置，对请求打上sid列表。传递给下游模块。另外一类配置是各个模块使用的抽样变量配置。程序在运行的时候根据不同sid取得不同的变量值，走不同的逻辑。 配置是通过一个配置配送模块进行的, 各个模块热加载配置。 具体打sid的过程 midway拿到流量分配配置后，解析配置，layermanager将按层解析配置，按层管理各个layer, layer中包含各个抽样节点，比如sid 999的流量区间为start=0, end=999 而且每层的sid都是按照start排序的。后续一个请求hash得到的一个整数就可以按照二分查找。 一个请求过来之后，就会一层一层地去匹配sid，每层最多匹配一个。 查找变量过程 下游模块加载抽样变量配置，热加载，按照变量名组织: struct SampleParam { uint32_t sid,; void* val; } std::unordered_map<std::string, SampleParam> sample_variables. 当代码要用到抽样变量时，先到sample_variable中查找，如果不到，则用默认值。 为了统计和评估，在日志中加入sid, 这样可以统计pv,ctr等信息。 流量切分 流量划分的粒度为0.1%， 我们将全部流量划分成10000等份，这样全部流量就是0~9999。对输入进行随机hash计算，可以将流量打散在全流量中。 流量可以按照以下几种方式来划分： 1) 按IP来进行划分(地域) 2) 按UID进行划分 3) 按cookie进行划分 4) 按query进行划分 首先将key对应的字符串用creat_sign_murmur64函数转成64位的整数，然后对10000取模，得到一个0~10000之间的整数。整个整数再去和各个抽样进行匹配，如果在某个抽样区间，则将请求打上对应的sid。 实现流量的分层 100%的流量很容易被用完，加入每个实验都需要10%的流量，这样同时只能做10个实验。而且有些实验要求更多的流量，比如有些实验要求在特定query下才走什么要的策略，假如只抽取1%的流量，这样再用这个流量进行query过滤，那就太少了，因此这类实验往往要求很多的流量，比如30%。这样势必会造成流量不够用的情况。 因此需要进行流量分层，将100%的流量正交成16个全流量，从逻辑上将实验流量变成原来的16倍。正交的意思是指第一层的某段很小的1%流量能够均匀地分散到其他层的100%上，而不是集中在其他层的某一段。 正交层之间几乎没有相互影响： 假如有实验1，有实验组exp_a和对照组control_a，各占流量1%,在第一层，第二层中有实验2，有实验组exp_a，占流量2%。如果不正交的话，导致实验1和实验2流量重叠，一个请求要么全部中实验一和实验二，要么全不中。这样两个实验就可能会相互影响了（即使两个实验不互斥）。如果保证正交的话，第一层实验1的流量均匀的落到第二层，这样就只有极少一部分流量落到实验2中的流量。 如果实验1和实验2互斥，比如都要在一个广告位上出广告，这样实验一和实验二必须都在同一层。 分层的实现是为不同层的creat_sign_murmur64函数设置不同的初始化种子字符串实现的，在创建层的时候为每个层分配一个全局唯一的id，作为层的初始化seed。具体代码如下： ErrorCode calc_sample_ratio(const boost::any &any_value, const std::string &seed, double &sample_ratio) { std::string val; if (boost_any_to_str(any_value, val) ! https://checkking.github.io/post/cs/link/ Mon, 24 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/cs/link/ 背景 项目的nginx日志太多了，需要迁移到其他磁盘，另外一个同学采用软链的方式迁移到其他磁盘上，这样不影响现有程序。对于软链和硬连接概念上还是有些模糊，所以总结一下，直接抄Quora上的一个通俗的回答. What is the difference between a hard link and a soft link? Have you ever given a thought to what happens when you store a file on your hard disk? I will show you. Let’s create a file first. touch myfile cat > myfile Hello, world! cat file should display this text: cat myfile Hello, world! Where do you think myfile is stored? An obvious and correct answer is your hard drive. https://checkking.github.io/post/nginx/nginx7/ Sat, 22 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/nginx/nginx7/ 背景 最近项目上线了广告Offer按照ecpm等排序策略功能，上线之后经常被pm骚扰，因为他经常想查看为什么一个offer没有展示等问题，每次都要帮他查看线上日志，过程很痛苦，占用了大把时间。必须要改变这种现状。 debug的用途 便于线上case追踪用，分析程序执行的每个环节。 设计要点 debug信息的层级关系 为了很好地阅读debug信息，必须将debug信息很好地组织起来，比如一个请求来了，在后台执行的时候需要经过好几步，stage1, stage2,state3,…,其中stage1中又有好几步，我们可以把这些信息按照树的结构组织起来： { "request": { "ip": "180.92.201.3", "uri": "/api/offer", "network": "wifi", "debugid": "8782399662" }, "process": { "stage_readOffers": [ { "offer_id": "3142", "type": "aio", "flags": { "d": 1, "x": false, "ne": -1 } }, { "offer_id": "3142", "type": "aio", "flags": { "d": 1, "x": false, "ne": -1 } }, ... ], "stage_filterOffers": [ { "offer_id": "3142", "type": "aio", "flags": { "d": 1, "x": false, "ne": -1 } }, . https://checkking.github.io/post/nginx/nginx6/ Sun, 16 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/nginx/nginx6/ nginx官网上的描述: Socket Sharding in NGINX Release 1.9.1 知乎上的一个网友的通俗解释: 作者：凡柯 链接：https://www.zhihu.com/question/51618274/answer/126729306 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 我来回答一下自己的问题，抛砖引玉吧先描述下Nginx的网络模型 1 nginx的master进程创建一系列的监听套接字（比如需要监听不同的端口，80，443等），下面都以监听80端口为例来说明。 2 fork出多个worker进程，这些worker进程继承了监听套接字。 3 而这种多进程监听同一端口的模型会有惊群现象（先不讨论内核是否解决了惊群，nginx作为一个跨平台的server，从自身解决了惊群），即监听套接字上有请求到来时，内核会唤醒所有的进程。 4 在linux平台下采用epoll网络事件驱动，每个worker创建自己的epoll。 5 Nginx的惊群解决手段： 如果有多个worker进程，且开启了accept_mutux 锁（默认开启）这时候每个worker不会将监听套接字加入到自己的epoll中，而是会去抢一把自旋锁，即对监听套接字“权力”，抢到的worker进程会将监听套接字加入自己的epoll中，accept新请求，然后释放锁。所以，如果没有这种强锁机制，每个worker的epoll中都会监视监听套接字，这样每次请求到来时，每个worker都会被唤醒，而最终accept这个请求的只能有一个，其它的worker的唤醒是浪费的。应该说在低并发情况下，这种处理机制会很好地提升cpu效率。现在很多实例证明：在并发很高的情况下，nginx这种处理惊群的机制会导致处理效率的下降，所以现在很多建议是关闭accept_mutux锁，这样每个worker中的epoll中都会监视监听套接字。幸运的是，从nginx的高版本开始，这个锁默认是已经关闭的了。为什么在高并发的情况下，关闭锁导致使惊群现象产生，也会提升性能呢？网上有个很形象的例子，这里我借用下：试想，有一群鸡（是真正的鸡），你撒谷粒给这群鸡吃。 a，一粒粒撒的时候，如果不加处理，每个鸡都会跳起来，但最终只有一只鸡能够吃到这粒米，所以在一粒粒撒的时候，需要有锁，不能让每个鸡都跳起来，这样浪费它们的精力，必须要让它们遵守秩序，一个个来（加锁） b，然而，如果你撒了一大把谷粒，这时候还让它们一个个来，岂不是很不合理，所以，在撒大把谷粒的情况下，这些鸡全部跳起来抢食才是科学的，这样才能更加快速地消耗掉这些谷粒。（不加锁）。 上面的例子虽然有些粗糙，但是很形象。 6 回到我们的话题SO_REUSEPORT这个选项，官方在nginx.19.1中支持这个，且经过测试，开启这个选项，会使得的nginx的性能提升3倍。具体测试可见：Socket Sharding in NGINX OSS Release 1.9.1 他们比较了三种情况，常规情况（开启锁），关闭锁，和开启SO_REUSEPORT。 对于关闭锁比开启锁提升性能，这个好理解。但SO_REUSEPORT这个。就是我的疑问了。 7 我的疑问是这样的，通过master fork出多个worker，这些worker都是共同监听了同一个端口，那么reuse_port这个，根据man手册描述，是让多个套接字共同监听同一个端口。但是master对于一个端口只创建了一个套接字，哪里来的多个套接字呢？从那个测试的图来看，好像在文件系统中对同一个端口关联了多个套接字。。。这科学么？8 如果内核真如测试的图中描述的那样，对于每个worker都有自己的监听套接字，且这些监听套接字都bind同一个端口，这样，当请求来时，内核会负责将这些请求均匀分配到不同的监听套接字，这样看来 确实会提升性能。但问题的关键是，对于同一个端口来说，这些不同的套接字是哪里来的呢？？ https://checkking.github.io/post/nginx/nginx5/ Sun, 16 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/nginx/nginx5/ ET&LT EPOLL事件有两种模型： 1. Level Triggered (LT) 水平触发 - socket接收缓冲区不为空 有数据可读 读事件一直触发 - socket发送缓冲区不满 可以继续写入数据 写事件一直触发 符合思维习惯，epoll_wait返回的事件就是socket的状态 Edge Triggered (ET) 边沿触发 socket的接收缓冲区状态变化时触发读事件，即空的接收缓冲区刚接收到数据时触发读事件 socket的发送缓冲区状态变化时触发写事件，即满的缓冲区刚空出空间时触发读事件 仅在状态变化时触发事件 nginx with ET 使用ET模式，可以便捷的处理EPOLLOUT事件，省去打开与关闭EPOLLOUT的epoll_ctl（EPOLL_CTL_MOD）调用。从而有可能让你的性能得到一定的提升。 例如你需要写出1M的数据，写出到socket 256k时，返回了EAGAIN，ET模式下，当再次返回EPOLLOUT时，继续写出待写出的数据，当没有数据需要写出时，不处理直接略过即可。而LT模式则需要先打开EPOLLOUT，当没有数据需要写出时，再关闭EPOLLOUT（否则会一直会返回EPOLLOUT事件） 当nginx处理大并发大流量的请求时，LT模式会出现较多的epoll_ctl调用用于开关EPOLLOUT，因此ET模式就更合适了 https://checkking.github.io/post/arch/nginx_event_module/ Sat, 15 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/arch/nginx_event_module/ 整体流程分析 先列出event模块相关定义的: static ngx_command_t ngx_events_commands[] = { { ngx_string("events"), NGX_MAIN_CONF|NGX_CONF_BLOCK|NGX_CONF_NOARGS, ngx_events_block, 0, 0, NULL }, ngx_null_command }; static ngx_core_module_t ngx_events_module_ctx = { ngx_string("events"), NULL, ngx_event_init_conf }; ngx_module_t ngx_events_module = { NGX_MODULE_V1, &ngx_events_module_ctx, /* module context */ ngx_events_commands, /* module directives */ NGX_CORE_MODULE, /* module type */ NULL, /* init master */ NULL, /* init module */ NULL, /* init process */ NULL, /* init thread */ NULL, /* exit thread */ NULL, /* exit process */ NULL, /* exit master */ NGX_MODULE_V1_PADDING }; 在ngx_init_cycle函数中，有下面部分代码: https://checkking.github.io/post/arch/nginx_probs1/ Mon, 10 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/arch/nginx_probs1/ 问题描述 线上机器有一台机器报警，说摸个url请求失败率达到25%，等到线上机器查看nginx错误日志，发现下面的滚屏； 2017/04/10 18:00:28 [alert] 2378#0: *35137710183 socket() failed (24: Too many open files) while connecting to upstream, client: 202.69.12.16, server: api.mobojoy.baidu.com, request: "GET /index.php?r=adfb/list&al=847dd82e152ec6ddeb104ba8439a684d&l=06e298ac92c301027067eea9a540dff4&p=48cfe1bbaabf62b82e4f979f4cbeb44f&hp=com.dianxinos.dxbs&lc=xiaobu_yz_gl_PRE_FREE&sdk=49 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "----" 2017/04/10 18:00:29 [crit] 2378#0: accept4() failed (24: Too many open files) 并且查看各个进程占用fd的情况： $ lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more 10259 2378 7520 16505 4273 5091 2661 5098 2508 5093 2201 5084 2183 5089 2001 5117 1934 5095 1927 5105 1911 5108 1906 5104 1809 5100 1713 5082 1631 5106 1336 5102 第一列为占用fd数，第二列为进程id，第一行就是nginx进程. https://checkking.github.io/post/cs/rpc_load_balance/ Sun, 09 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/cs/rpc_load_balance/ 概述 LALB全称Locality-aware load balancing，是一个能把请求及时、自动地送到延时最低的下游的负载均衡算法，特别适合混合部署环境。 LALB可以解决的问题： - 下游的机器配置不同，访问延时不同，round-robin和随机分流效果不佳。 - 下游服务和离线服务或其他服务混部，性能难以预测。 - 自动地把大部分流量送给同机部署的模块，当同机模块出问题时，再跨机器。 - 优先访问本机房服务，出问题时再跨机房。 背景 最常见的分流算法是round robin和随机。这两个方法的前提是下游的机器和网络都是类似的，但在目前的线上环境下，特别是混部的产品线中，已经很难成立，因为： - 每台机器运行着不同的程序组合，并伴随着一些离线任务，机器的可用资源在持续动态地变化着。 - 机器配置不同。 - 网络延时不同。 这些问题其实一直有，但往往被OP辛勤的机器监控和替换给隐藏了。框架层面也有过一些努力，比如我厂UB框架中的WeightedStrategy是根据下游的cpu占用率来进行分流，但明显地它解决不了延时相关的问题，甚至cpu的问题也解决不了：因为它被实现为定期reload一个权值列表，可想而知更新频率高不了，等到负载均衡反应过来，一大堆请求可能都超时了。并且这儿有个数学问题：怎么把cpu占用率转为权值。假设下游差异仅仅由同机运行的其他程序导致，机器配置和网络完全相同，两台机器权值之比是cpu idle之比吗？假如是的，当我们以这个比例给两台机器分流之后，它们的cpu idle应该会更接近对吧？而这会导致我们的分流比例也变得接近，从而使两台机器的cpu idle又出现差距。你注意到这个悖论了吗？这些因素使得这类算法的实际效果和那两个基本算法没什么差距，甚至更差，用者甚少。 我们需要一个能自适应下游负载、规避慢节点的通用分流算法。 Locality-aware Locality-aware load balancing，能根据下游节点的负载分配流量，还能快速规避失效的节点，在很大程度上，这种算法的延时也是全局最优的。基本原理非常简单： 以下游节点的吞吐除以延时作为分流权值。 比如只有两台下游节点，W代表权值，QPS代表吞吐，L代表延时，那么W1 = QPS1 / L1和W2 = QPS2 / L2分别是这两个节点的分流权值，分流时随机数落入的权值区间就是流量的目的地了。 一种分析方法如下： 稳定状态时的QPS显然和其分流权值W成正比，即W1 / W2 ≈ QPS1 / QPS2。 根据分流公式又有：W1 / W2 = QPS1 / QPS2 * (L2 / L1)。 故稳定状态时L1和L2应当是趋同的。当L1小于L2时，节点1会更获得相比其QPS1更大的W1，从而在未来获得更多的流量，直到其延时高于平均值或没有更多的流量。 注意这个算法并不是按照延时的比例来分流，不是说一个下游30ms，另一个60ms，它们的流量比例就是60 / 30。而是30ms的节点会一直获得流量直到它的延时高于60ms，或者没有更多流量了。以下图为例，曲线1和曲线2分别是节点1和节点2的延时与吞吐关系图，随着吞吐增大延时会逐渐升高，接近极限吞吐时，延时会飙升。左下的虚线标记了QPS=400时的延时，此时虽然节点1的延时有所上升，但还未高于节点2的基本延时（QPS=0时的延时），所以所有流量都会分给节点1，而不是按它们基本延时的比例（图中大约2:1）。当QPS继续上升达到1600时，分流比例会在两个节点延时相等时平衡，图中为9 : 7。很明显这个比例是高度非线性的，取决于不同曲线的组合，和单一指标的比例关系没有直接关联。在真实系统中，延时和吞吐的曲线也在动态变化着，分流比例更加动态。 https://checkking.github.io/post/mind/tech_road/ Sun, 09 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/mind/tech_road/ 晚上在规划自己接下来的工作和学习时，有些疑惑，最大的疑惑是对于目前的工作，业务方面和技术方面自己一点都不感兴趣的情况下，要不要选择离职，或者不离职的情况下，怎么应对目前工作内容多，对自己成长没有太大帮助的工作内容。 我一直比较纠结的是，我一直舍不多公司内部的技术资源，有很多可以学习的资料，目前来说这些技术没有成为自己的一个体系，出去也不一定能找到一份很满意的工作。还是挺想再积累一段时间再走。 但是现在每天被工作琐碎的工作内容所困扰，占用了自己全部的工作时间，回家之后就很累，根本没有时间给自己充电，而且这些活是永远干不完的。这样自己的危机感就会越来越大。选择不加班对于工作又会有愧疚感，觉得是不负责任的一种表现，怕影响自己的晋升。 但是读了陈皓老师的《技术人员的发展之路》，才豁然开朗，我决定不再加班了。不会为了自己在领导或者其他员工心中的印象，不用在意当前的晋升和升职了。 当前阶段我觉得自己最重要的事是提高自己的学习能力和解决难题的能力。而《技术人员的发展之路》中的一段话，让我醍醐灌顶，找到了当前自己所面临的问题的解决方案： 如果你不幸呆在了一个搬砖的地方，天天被业务压得喘不过气来，我建议你宁可让你的项目延期被老板骂，也要把时间挤出来努力学习基础知识，多掌握一些技术（很多技术在思路上是相通的），然后才能有机会改变自己目前的状况。因为，比起你的个人未来，项目延期被老板骂、绩效不好拿不到奖金，都不是什么事儿。 他还提到的追求自由的生活: 第一层自由——工作自由。人的第一层自由的境界是——“工作自由”，我到不是说你在工作单位上可以很自由，虽然有特例，但并不普遍。我想说的“工作自由”是——你不会有失业危机感了。也就是说，你成了各个公司的抢手货，你不但不愁找不到工作，而且你是完全不愁找不到好工作。试想一下，如果是工作来找你，一方面，你就有真正意义上的工作选择权了，另一方面，你都不愁工作了，你完全就可以随时离职去干你想干的事了。此时，你就达到了“工作自由”。 第二层自由——技能自由。工作自由已是不错，不过前提是你还是需要依赖于别人提供的工作机会。而技能自由则是你可以用自己的技能养活自己，而不需要去公司里工作。也就是所谓的自由职业者了，社会上，这样的人也不少，比如，一些健身体育教练、设计师、翻译者、作者……这些都可以算是自由职业者，程序员这个职业中只要不是搬砖的，有想法的，就有可以成为自由积业者的潜质，想一想，你拥有的编程能力，其实是一种创造的能力，也就是创造力，只要你Make Something People Want（YC创业公司的slogan），你是完全可以通过自己的技能来养活自己的。如果你通过某些自动化的东西，或是你在App上做了一个软件个体户，让自己的收入不断，甚至你做了一个开源软件，社区每个月都给你捐款捐到比你打工挣的还多，那么你就真正的有了技能自由了。 第三层自由——物质自由。我把财务自由换了一种说法。我个人觉得，除了有个好爸爸之外这种特例的情况，如果你想有物质自由的话，本质上来说，你一定要学会投资，投资不一定是你的钱，时间也是一种财富，年轻更是，你怎么投资你的时间还有你的青春？你要把你的投资投到什么样的事，什么样的人？对于投资这个事，风险也比较大。但是，人生不敢冒险可能才是最大的冒险。这个世界有很多技术不是你能看书学来的，而要只能在实战中学会的，比如：游泳。投资可能也是一种。只有真正懂投资的人，或是运气非常好的人，才可能实现物质自由。 这个观点也是我所非常赞同的。 https://checkking.github.io/post/cs/timer_keeping/ Sat, 08 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/cs/timer_keeping/ 在几点几分做某件事是RPC框架的基本需求，这件事比看上去难。 让我们先来看看系统提供了些什么： posix系统能以signal方式告知timer触发，不过signal逼迫我们使用全局变量，写async-signal-safe的函数，在面向用户的编程框架中，我们应当尽力避免使用signal。linux自2.6.27后能以fd方式通知timer触发，这个fd可以放到epoll中和传输数据的fd统一管理。唯一问题是：这是个系统调用，且我们不清楚它在多线程下的表现。 为什么这么关注timer的开销?让我们先来看一下RPC场景下一般是怎么使用timer的： 在发起RPC过程中设定一个timer，在超时时间后取消还在等待中的RPC。几乎所有的RPC调用都有超时限制，都会设置这个timer。 RPC结束前删除timer。大部分RPC都由正常返回的response导致结束，timer很少触发。 你注意到了么，在RPC中timer更像是”保险机制”，在大部分情况下都不会发挥作用，自然地我们希望它的开销越小越好。一个几乎不触发的功能需要两次系统调用似乎并不理想。那在应用框架中一般是如何实现timer的呢？谈论这个问题需要区分“单线程”和“多线程”: 在单线程框架中，比如以libevent, libev为代表的eventloop类库，或以GNU Pth, StateThreads为代表的coroutine / fiber类库中，一般是以小顶堆记录触发时间。epoll_wait前以堆顶的时间计算出参数timeout的值，如果在该时间内没有其他事件，epoll_wait也会醒来，从堆中弹出已超时的元素，调用相应的回调函数。整个框架周而复始地这么运转，timer的建立，等待，删除都发生在一个线程中。只要所有的回调都是非阻塞的，且逻辑不复杂，这套机制就能提供基本准确的timer。不过就像Threading Overview中说的那样，这不是RPC的场景。 在多线程框架中，任何线程都可能被用户逻辑阻塞较长的时间，我们需要独立的线程实现timer，这种线程我们叫它TimerThread。一个非常自然的做法，就是使用用锁保护的小顶堆。当一个线程需要创建timer时，它先获得锁，然后把对应的时间插入堆，如果插入的元素成为了最早的，唤醒TimerThread。TimerThread中的逻辑和单线程类似，就是等着堆顶的元素超时，如果在等待过程中有更早的时间插入了，自己会被插入线程唤醒，而不会睡过头。这个方法的问题在于每个timer都需要竞争一把全局锁，操作一个全局小顶堆，就像在其他文章中反复谈到的那样，这会触发cache bouncing。同样数量的timer操作比单线程下的慢10倍是非常正常的，尴尬的是这些timer基本不触发。 我们重点谈怎么解决多线程下的问题。 一个惯例思路是把timer的需求散列到多个TimerThread，但这对TimerThread效果不好。注意我们上面提及到了那个“制约因素”：一旦插入的元素是最早的，要唤醒TimerThread。假设TimerThread足够多，以至于每个timer都散列到独立的TImerThread，那么每次它都要唤醒那个TimerThread。 “唤醒”意味着触发linux的调度函数，触发上下文切换。在非常流畅的系统中，这个开销大约是3-5微秒，这可比抢锁和同步cache还慢。这个因素是提高TimerThread扩展性的一个难点。多个TimerThread减少了对单个小顶堆的竞争压力，但同时也引入了更多唤醒。 另一个难点是删除。一般用id指代一个Timer。通过这个id删除Timer有两种方式：1.抢锁，通过一个map查到对应timer在小顶堆中的位置，定点删除，这个map要和堆同步维护。2.通过id找到Timer的内存结构，做个标记，留待TimerThread自行发现和删除。第一种方法让插入逻辑更复杂了，删除也要抢锁，线程竞争更激烈。第二种方法在小顶堆内留了一大堆已删除的元素，让堆明显变大，插入和删除都变慢。 第三个难点是TimerThread不应该经常醒。一个极端是TimerThread永远醒着或以较高频率醒过来（比如每1ms醒一次），这样插入timer的线程就不用负责唤醒了，然后我们把插入请求散列到多个堆降低竞争，问题看似解决了。但事实上这个方案提供的timer精度较差，一般高于2ms。你得想这个TimerThread怎么写逻辑，它是没法按堆顶元素的时间等待的，由于插入线程不唤醒，一旦有更早的元素插入，TimerThread就会睡过头。它唯一能做的是睡眠固定的时间，但这和现代OS scheduler的假设冲突：频繁sleep的线程的优先级最低。在linux下的结果就是，即使只sleep很短的时间，最终醒过来也可能超过2ms，因为在OS看来，这个线程不重要。一个高精度的TimerThread有唤醒机制，而不是定期醒。 另外，更并发的数据结构也难以奏效，感兴趣的同学可以去搜索”concurrent priority queue”或”concurrent skip list”，这些数据结构一般假设插入的数值较为散开，所以可以同时修改结构内的不同部分。但这在RPC场景中也不成立，相互竞争的线程设定的时间往往聚集在同一个区域，因为程序的超时大都是一个值，加上当前时间后都差不多。 这些因素让TimerThread的设计相当棘手。由于大部分用户的qps较低，不足以明显暴露这个扩展性问题，在r31791前我们一直沿用“用一把锁保护的TimerThread”。TimerThread是baidu-rpc在默认配置下唯一的高频竞争点，这个问题是我们一直清楚的技术债。随着baidu-rpc在高qps系统中应用越来越多，是时候解决这个问题了。r31791后的TimerThread解决了上述三个难点，timer操作几乎对RPC性能没有影响，我们先看下性能差异。 那新TimerThread是如何做到的？ 一个TimerThread而不是多个。 创建的timer散列到多个Bucket以降低线程间的竞争，默认12个Bucket。 Bucket内不使用小顶堆管理时间，而是链表 + nearest_run_time字段，当插入的时间早于nearest_run_time时覆盖这个字段，之后去和全局nearest_run_time（和Bucket的nearest_run_time不同）比较，如果也早于这个时间，修改并唤醒TimerThread。链表节点在锁外使用ResourcePool分配。 删除时通过id直接定位到timer内存结构，修改一个标志，timer结构总是由TimerThread释放。 TimerThread被唤醒后首先把全局nearest_run_time设置为几乎无限大(max of int64)，然后取出所有Bucket内的链表，并把Bucket的nearest_run_time设置为几乎无限大(max of int64)。TimerThread把未删除的timer插入小顶堆中维护，这个堆就它一个线程用。在每次运行回调或准备睡眠前都会检查全局nearest_run_time， 如果全局更早，说明有更早的时间加入了，重复这个过程。 这里勾勒了TimerThread的大致工作原理，工程实现中还有不少细节问题，具体请阅读timer_thread.h和timer_thread.cpp。 struct TimerThreadOptions { // Scheduling requests are hashed into different bucket to improve // scalability. However bigger num_buckets may NOT result in more scalable // schedule() because bigger values also make each buckets more sparse // and more likely to lock the global mutex. https://checkking.github.io/post/cs/timer_impl/ Sat, 08 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/cs/timer_impl/ 定时器 在一般的服务端程序设计中，与时间有关的常见任务有： 获取当前时间，计算时间间隔 时区转换与日期计算；把纽约当地时间转换成上海当地时间；2011-02-05之后的100天是几月几号星期几;等等。 定时操作，比如在预定的时间执行任务，或者在一段延时之后执行任务。 这里我们讨论第3项。Linux计时函数有下面这些： time(2) / time_t (s) ftime(3) / struct timeb (ms) gettimeofday(2) / struct timeval (us) clock_gettime(2) / struct timespec (ns) 定时函数，用于让程序等待一段时间或安排计划任务： sleep(3) alarm(2) usleep(3) nanosleep(2) clock_nanosleep(2) gettimer(2) / settimer(2) timer_create(2) / timer_settime(2) / timer_gettime(2) / timer_delete(2) timerfd_create(2) / timerfd_gettime(2) / timerfd_settime(2) 我的取舍如下： (计时) 只使用gettimeofday(2)来获取当前时间 (定时) 只使用timerfd_*系列函数. 因为，gettimeofday(2)的精度足够，timerfd_create(2) 把时间变成一个文件描述符，该“文件”在定时器超时那一刻变得可读，这样就能很方便地融入select(2)/poll(2)框架中，用统一的方式来处理IO事件和超时事件。 定时器数据结构 TimerQueue需要高效地组织目前尚未到期的Timer，能够快速地根据当前时间找到已经到期的Timer，也要能高效添加和删除Timer。最简单的TimerQueue以按照到期时间排好序的线性表为数据结构，查找复杂度为O(N)。 另外一种做法是用大顶堆或小顶堆，这样复杂度降为O(logN)，但是C++标准库的make_heap()等函数不能高效地删除heap中间的某个元素，需要我们自己实现。 还有一种做法是使用二叉搜索树(如std::set/std::map)，把Timer按到期时间先后排好序。操作的复杂度仍然是O(logN)，不过memeory locality比heap要差一些,实际速度可能略慢。 但是我们不能够直接用map，因为这样无法处理两个Timer到期时间相同的情况。可以用std::pair为key, 这样即便两个Timer到期时间相同，他们的地址也是不同的。下面是TimerQueue的接口: class TimerQueue : boost::noncopyable { public: TimerQueue(EventLoop* loop); ~TimerQueue(); /// /// Schedules the callback to be run at given time, /// repeats if @c interval > 0. https://checkking.github.io/post/cs/connection_number_limitation/ Sat, 08 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/cs/connection_number_limitation/ 在网络编程中，我们通常用Reactor模式来处理并发连接。listening scoket是一种特殊的IO对象，当有新连接达到时，此listening文件描述符变得可读(POLLIN),epoll_wait返回这一事件。然后我们用accept(2)系统返回获得新连接的socket文件描述符。 serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) serversocket.bind(('', 2006)) serversocket.listen(5) serversocket.setblocking(0) poll = select.poll() poll.register(serversocket.fileno(), select.POLLIN) connections = {} while True: events = poll.poll(1000) for fileno, event in events: # (1) if fileno == serversocket.fileno(): (clientsocket, address) = serversocket.accept() # (2) clientsocket.setblocking(0) poll.register(clientsocket.fileno(), select.POLLIN) connections[clientsocket.fileno()] = client.socket elif event & select.POLLIN: # ... 假设(2)处返回EMFILE该如何应对？这意味着本进程的文件描述符已经达到上限，无法为新连接建立socket文件描述符。但是，既然没有scoekt文件描述符来表示连接，我们就无法close(2)它。程序继续运行，回到(1)处再一次调用epoll_wait，这时候epoll_wait会立刻返回，因为新连接还等待处理，listening fd还是可读的。这样程序就立刻陷入busy loop,CPU占用率接近100%. 这既影响同一event loop上的连接，也影响同一机器上的其他服务。 这种情况下，有以下几种解决方案： 提高进程的文件描述符数目。治标不治本。 死等。 退出程序，小题大作 关闭listening fd，那什么时候重新打开呢？ 改用edge trigger，如果漏掉一次accept(2),程序再也不会收到新连接。 准备一个空闲的文件描述符，遇到这种情况，先关闭这个空闲描述符，获得一个文件描述符的名额；再accept(2)拿到新socket连接的描述符；随后立刻close(2)它，这样就优雅地断开了客户端连接；最后重新打开一个空闲文件，把”坑”站住，以备再次出现这种情况时使用。 私以为第6种方案最佳，muduo的Acceptor正是用这种方案，相关代码如下： https://checkking.github.io/post/cs/timer_wheel/ Sat, 08 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/cs/timer_wheel/ 如果一个连接连续几秒内没有收到数据，就把它断开，为此有两种简单、粗暴的做法： 每个连接保存”最后收到数据的时间lastReceiveTime“， 然后用一个定时器，每秒 遍历一遍所有的连接，断开那些(now - connection.lastReceiveTime) > 8s的connection。 这种做法全局只有一个repeated timer, 不过每次timeout都要检查全部连接，如果连接数目 比较大(几千万), 这一步可能比较费时。 每个连接设置一个one-shot timer, 超时定为8s, 在超时的时候就断开本连接。当然， 每次收到数据要去更新timer。这种做法需要很多one-shot timer, 会频繁地更新timers。如果连接数目比较大，可能对EventLoop的 TimerQueue造成压力。 使用timing wheel能够避免上述两种做法的缺点。timing wheel可以翻译为”时间轮盘”或”刻度盘”。 timing wheel原理 定时轮是一种数据结构，其主体是一个循环列表（circular buffer），每个列表中包含一个称之为槽（slot）的结构（附图）。 至于 slot 的具体结构依赖具体应用场景。 以本文开头所述的管理大量连接 timeout 的场景为例，描述一下 timing wheel的具体实现细节。 定时轮的工作原理可以类比于始终，如上图箭头（指针）按某一个方向按固定频率轮动，每一次跳动称为一个 tick。 这样可以看出定时轮由个3个重要的属性参数，ticksPerWheel（一轮的tick数），tickDuration（一个tick的持续时间） 以及 timeUnit（时间单位），例如 当ticksPerWheel=60，tickDuration=1，timeUnit=秒，这就和现实中的始终的秒针走动完全类似了。 这里给出一种简单的实现方式，指针按 tickDuration 的设置进行固定频率的转动，其中的必要约定如下： 新加入的对象总是保存在当前指针转动方向上一个位置 相等的对象仅存在于一个 slot 中 指针转动到当前位置对应的 slot 中保存的对象就意味着 timeout 了 在 Timing Wheel 模型中包含4种操作： Client invoke： START_TIMER(Interval, Request_ID, Expiry_Action) STOP_TIMER(Request_ID) Timer tick invoke： https://checkking.github.io/post/cs/pb_serialize/ Fri, 07 Apr 2017 21:07:16 +0800 https://checkking.github.io/post/cs/pb_serialize/ 这几天把google protobuf官方文档通读了一遍, 总觉得对message序列化后的内容理解的不够透彻，因此动手操作一遍，分析一下message序列化后的内容。程序代码是官网的。 proto文件内容 // file addressbook.proto syntax = "proto3"; package tutorial; message Person { string name = 1; int32 id = 2; // Unique ID number for this person. string email = 3; enum PhoneType { HOME = 0; MOBILE = 1; WORK = 2; } message PhoneNumber { string number = 1; PhoneType type = 2; } repeated PhoneNumber phone = 4; } message AddressBook { repeated Person person = 1; } service SearchService { rpc Search (Person) returns (Person); } 序列化写入程序 #include <iostream> #include <fstream> #include <string> #include "addressbook. https://checkking.github.io/post/cs/pb_zero_copy/ Tue, 21 Mar 2017 21:07:16 +0800 https://checkking.github.io/post/cs/pb_zero_copy/ 引言 我们在序列化、反序列化 Protobuf message 时为了最小化内存拷贝，可以实现其提供的 ZeroCopyStream（包括 ZeroCopyOutputStream 和 ZeroCopyInputStream）接口类，ZeroCopyStream 要求能够进行 buffer 的分配，这体现在一个名为 Next 的接口上，这样做的好处是避免进行内存的拷贝，为了方便理解，我们来看一下 ZeroCopyInputStream 和传统的 stream 的对比. 典型的做法 /* 我们调用 input stream 的 Read 从内存中读取数据到 buffer * 这里进行了一次拷贝操作，也就是拷贝内存中的数据到 buffer 中 * 之后 DoSomething 才能处理此数据 */ char buffer[BUFFER_SIZE]; input->Read(buffer, BUFFER_SIZE); DoSomething(buffer, BUFFER_SIZE); ZeroCopyStream /* * 使用 Next 接口的做法，input stream 内部有责任提供（分配）buffer * 也就是说，DoSomething 可以直接操作内部的内存，而无需拷贝后再操作 * 这就避免了一次内存拷贝 */ const void* buffer; int size; input->Next(&buffer, &size); DoSomething(buffer, size); protbuff 相关接口 protobuf作为一个消息格式的利器，在io的接口设计上也非常巧妙，本文主要想介绍下其中ZeroCopy的思想以及用途。 https://checkking.github.io/post/cs/pb_reflection/ Tue, 21 Mar 2017 21:07:16 +0800 https://checkking.github.io/post/cs/pb_reflection/ 背景 之前做的一个广告模块，要用用户请求构造特征值去请求机器学习模型模块。我这个模块与下游模块的接口之间的序列化协议是protobuf，与上游机器学习模块的序列化协议是公司内部的，而且要求将特征名，特征值都表示成字符串传给机器学习模块做在线预测。因此这当中就有一个转化需求：将protobuf转成map。 反射相关接口 要介绍pb的反射功能，先看一个相关的UML示例图： 各个类以及接口说明: Message Person是自定义的pb类型，继承自Message. MessageLite作为Message基类，更加轻量级一些。 通过Message的两个接口GetDescriptor/GetReflection，可以获取该类型对应的Descriptor/Reflection。 Descriptor Descriptor是对message类型定义的描述，包括message的名字、所有字段的描述、原始的proto文件内容等。 本文中我们主要关注跟字段描述相关的接口，例如： 获取所有字段的个数：int field_count() const 获取单个字段描述类型FieldDescriptor的接口有很多个，例如 const FieldDescriptor* field(int index) const;//根据定义顺序索引获取 const FieldDescriptor* FindFieldByNumber(int number) const;//根据tag值获取 const FieldDescriptor* FindFieldByName(const string& name) const;//根据field name获取 FieldDescriptor FieldDescriptor描述message中的单个字段，例如字段名，字段属性(optional/required/repeated)等。 对于proto定义里的每种类型，都有一种对应的C++类型，例如： enum CppType { CPPTYPE_INT32 = 1, //TYPE_INT32, TYPE_SINT32, TYPE_SFIXED32 } 获取类型的label属性： enum Label { LABEL_OPTIONAL = 1, //optional LABEL_REQUIRED = 2, //required LABEL_REPEATED = 3, //repeated MAX_LABEL = 3, //Constant useful for defining lookup tables indexed by Label. https://checkking.github.io/post/cs/pb_update_message_roles/ Tue, 21 Mar 2017 21:07:16 +0800 https://checkking.github.io/post/cs/pb_update_message_roles/ If an existing message type no longer meets all your needs – for example, you’d like the message format to have an extra field – but you’d still like to use code created with the old format, don’t worry! It’s very simple to update message types without breaking any of your existing code. Just remember the following rules: - Don’t change the numeric tags for any existing fields. - Any new fields that you add should be optional or repeated. https://checkking.github.io/post/cs/pb_internal/ Sun, 19 Mar 2017 21:07:16 +0800 https://checkking.github.io/post/cs/pb_internal/ Base 128 Varints 官方描述：Each byte in a varint, except the last byte, has the most significant bit (msb) set – this indicates that there are further bytes to come. The lower 7 bits of each byte are used to store the two’s complement representation of the number in groups of 7 bits, least significant group first. 也就是： 除了最后一个字节，varint中的每个字节的最高位设为1，表示后面还有字节出现 每个字节的低7位看成是一个组（group），这个组和他相邻的下一个7位组共同存储某个整形的“组合表示”，最低有效组在前面。 例子： 1. 一个字节。下面只有一个字节，所以最高位是0，表示十进制1 0000 0001 两个字节 bash 1010 1100 0000 0010 由于第一个字节后面还有一个字节，所以第一个字节的最高位设置为1，表示后面还有后继字节，第二个字节的最高位为0。去掉每个字节的最高位，我们对两个字节进行分组。第一个7位组：0101100，第二个7位组：0000010，组合起来就是：0101100 0000010。 由于protobuf采用小端字节序(关于字节序)，也就是数据的低位保存在内存的低地址中，调整为0101100 0000010, 十进制为2^8 + 2^5 + 2^3 + 2^2 = 300 300 的二进制表示为 100101100，通过 Varint 编码后的二进制表示为 10101100 00000010，详细过程如下： message数据格式 比如我们定义了proto https://checkking.github.io/post/cs/nonblock_socket_conn/ Wed, 15 Mar 2017 21:07:16 +0800 https://checkking.github.io/post/cs/nonblock_socket_conn/ 我们知道，如果socket为TCP套接字，则connect函数会激发TCP的三次握手过程，而三次握手是需要一些时间的，内核中对connect的超时限制是75秒，就是说如果超过75秒则connect会由于超时而返回失败。但是如果对端服务器由于某些问题无法连接，那么每一个客户端发起的connect都会要等待75才会返回，因为socket默认是阻塞的。对于一些线上服务来说，假设某些对端服务器出问题了，在这种情况下就有可能引发严重的后果。或者在有些时候，我们不希望在调用connect的时候阻塞住，有一些额外的任务需要处理。 这种场景下，我们就可以将socket设置为非阻塞，如下代码： int flags = fcntl(c_fd, F_GETFL, 0); if(flags < 0) { return 0; } fcntl(c_fd, F_SETFL, flags | O_NONBLOCK); 当我们将socket设置为NONBLOCK后，在调用connect的时候，如果操作不能马上完成，那connect便会立即返回，此时connect有可能返回-1， 此时需要根据相应的错误码errno，来判断连接是否在继续进行。比较完整的做法如下: int sockfd = sockets::createNonblockingOrDie(_serverAddr.family()); int ret = sockets::connect(sockfd, _serverAddr.getSockAddr()); int savedErrno = (ret == 0) ? 0 : errno; switch (savedErrno) { case 0: case EINPROGRESS: case EINTR: case EISCONN: connecting(sockfd); break; case EAGAIN: case EADDRINUSE: case EADDRNOTAVAIL: case ECONNREFUSED: case ENETUNREACH: retry(sockfd); break; case EACCES: case EPERM: case EAFNOSUPPORT: case EALREADY: case EBADF: case EFAULT: case ENOTSOCK: LOG_ERROR << "connect error in Connector::startInLoop " << savedErrno; sockets::close(sockfd); break; default: LOG_ERROR << "Unexpected error in Connector::startInLoop " << savedErrno; sockets::close(sockfd); break; } 使用非阻塞 connect 需要注意的问题是： 1. https://checkking.github.io/post/cs/tcp_self_conn/ Sun, 12 Mar 2017 21:07:16 +0800 https://checkking.github.io/post/cs/tcp_self_conn/ 现象重现 在linux主机下运行下面的python脚本，等待一会即可出现。 import socket import time connected=False while (not connected): try: sock = socket.socket(socket.AF_INET,socket.SOCK_STREAM) sock.setsockopt(socket.IPPROTO_TCP,socket.TCP_NODELAY,1) sock.connect(('127.0.0.1',55555)) connected=True except socket.error,(value,message): print message if not connected: print "reconnect" print "tcp self connection occurs!" print "try to run follow command : " print "netstat -an|grep 55555" time.sleep(1800) 截图如下： tcp自连接出现了！ 原因分析 从上面的python脚本中，可以看到它只是在不断地尝试连接55555这个端口，并且是没有socket监听这个端口，那么为何最后却建立连接了呢？原因在于客户端在连接服务端时，如果没有指定端口号，系统会随机分配一个。随机就意味着可能分配一个和目的端口一样的数字，此时就会出现自连接情况了。因为对于tcp协议来讲，连接的流程是走的通，三次握手整个阶段都合法，连接自然可以建立。 自连接的坏处显而易见，当程序去connect一个不处于监听的端口时，必然期待其连接失败，如果自连接出现，就意味着该端口被占用了，那么： 真正需要监听该端口的服务会启动失败，抛出端口已被占用的异常。 客户端无法正常完成数据通信，因为这是个自连接，并不是一个正常的服务。 解决思路 解决办法也很简单，只要保证客户端随机的端口不会和服务监听的端口相同就可以了。那么我们得先了解随机的范围，这个范围对应linux的/etc/sysctl.conf的net.ipv4.ip_local_port_range参数，其默认值是32768 61000。也就是说随机端口会在这个范围内出现，试验中我们选定了55555这个端口，所以出现了自连接现象。此时只要限定服务监听在32768端口以下，就不会出现自连接现象了。当然，你可以修改这个配置，只要注意保证监听端口不再配置范围内就可以避免自连接问题了。 t https://checkking.github.io/post/cs/spurious_wakeup/ Mon, 06 Mar 2017 21:07:16 +0800 https://checkking.github.io/post/cs/spurious_wakeup/ pthread_cond_wait通常用法 pthread_cond_wait的通常使用方法如下： #include <pthread.h> struct msg { struct msg *m_next; /* ... more stuff here ... */ }; struct msg *workq; pthread_cond_t qready = PTHREAD_COND_INITIALIZER; pthread_mutex_t qlock = PTHREAD_MUTEX_INITIALIZER; void process_msg(void) { struct msg *mp; for (;;) { pthread_mutex_lock(&qlock); while (workq == NULL) { // (1) pthread_cond_wait(&qready, &qlock); } } mp = workq; workq = mp->m_next; pthread_mutex_unlock(&qlock); /* now process the message mp */ } void enqueue_msg(struct msg *mp) { pthread_mutex_lock(&qlock); mp->m_next = workq; workq = mp; pthread_mutex_unlock(&qlock); pthread_cond_signal(&qready); } (1)处为什么要用while, 而不是简单的if呢？这是因为为了避免Spurious wakeup。 https://checkking.github.io/post/lang/cpp3/ Sat, 04 Mar 2017 21:07:16 +0800 https://checkking.github.io/post/lang/cpp3/ 对象销毁不容易 对一般成员函数而言，做到线程安全的办法是让他们顺次执行，而不要并发执行（不要同时读写共享状态），也就是让每个成员函数的临界区不重叠。不过这里有一个隐含条件：成员函数用来保护临界区的互斥器本身是有效的。而析构函数破坏了这一假设，它会把mutex成员变量销毁掉。请看下面的例子： Foo::~Foo() { MutexLockGuard lock(_mutex); // free internal state (1) } void Foo::update() { MutexLocakGuard lock(_mutex); // (2) // make use of internal state } 此时，有A,B两个线程都能看到Foo对象x, 线程A即将销毁x，而线程B正准备调用x->update(). extern Foo* x; // visibale by all threads // thread A delete x; x = NULL; // thread B if (x) { x->update(); } 这里有一个race condition: 线程执行到(1)处，已经持有了互斥锁，即将继续往下执行。 线程B通过了if(x)检查（此时x被销毁，但还没有执行x=NULL），接着阻塞在(2)处。 接下来会发生什么是不确定的，因为析构函数会把_mutex销毁，那么(2)处有可能永远阻塞下去，有可能进入临界区，然后core dump，或更糟糕的情况。 这个例子说明，作为class的数据成员MutexLock只能同步本class的其他数据成员的读写，他不能保护安全地析构。因为MutexLock成员的生命周期最多和本class一样长，而析构函数可说是发生在对象身故之后。 另外，如果要同时读写一个class的两个对象，有潜在的死锁可能。比如说有swap这个函数： void swap(Conter& a, Counter& b) { MutexLockGuard aLock(a. https://checkking.github.io/post/lang/cpp2/ Tue, 28 Feb 2017 21:07:16 +0800 https://checkking.github.io/post/lang/cpp2/ 以前都没有用过enable_shared_from_this模板类，虽然经常遇到但是也没怎么去关注，今天抽时间好好学习了下enable_shared_from_this模板类，发现在使用shared_ptr模板类和enable_shared_from_this模板类时有许多陷阱的，故记录于此。 什么时候该使用enable_shared_from_this模板类 在看下面的例子之前，简单说下使用背景，单有一个类，某个函数需要返回当前对象的指针，我们返回的是shared_ptr，为什么使用智能指针呢，这是因为：当我们使用智能指针管理资源时，必须统一使用智能指针，而不能再某些地方使用智能指针，某些地方使用原始指针，否则不能保持智能指针的语义，从而产生各种错误。好了，介绍完背景，看下面的一段小程序： #include <iostream> #include <boost/shared_ptr.hpp> class Test { public: //析构函数 ~Test() { std::cout << "Test Destructor." << std::endl; } //获取指向当前对象的指针 boost::shared_ptr<Test> GetObject() { boost::shared_ptr<Test> pTest(this); return pTest; } }; int main(int argc, char *argv[]) { { boost::shared_ptr<Test> p( new Test( )); boost::shared_ptr<Test> q = p->GetObject(); } return 0; } 程序输出： Test Destructor. Test Destructor. 从上面的输出你发现了什么，很明显的发现只创建new了一个Test对象，但是却调用了两次析构函数，这对程序来说肯定是一个灾难。为什么会出现这种情况呢？main函数中的boost::shared_ptr<Test> p( new Test( )); 将shared_ptr中引用计数器的值设置为1，而在GetObject函数中又通过boost::shared_ptr<Test> pTest(this)又将shared_ptr中的引用计数器的值增加了1，故在析构时一个Test对象被析构了两次。即产生这个错误的原因是通过同一个Test指针对象创建了多个shared_ptr，这是绝对禁止的。同时这也提醒我们在使用shared_ptr时一定不能通过同一个指针对象创建一个以上的shared_ptr对象。那么有什么方法从一个类的成员函数中获取当前对象的shared_ptr呢，其实方法很简单：只需要该类继承至enable_shared_from_this模板类,然后在需要shared_prt的地方调用enable_shared_from_this模板类的成员函数shared_from_this()即可，下面是改进后的代码： #include <iostream> #include <boost/enable_shared_from_this.hpp> #include <boost/shared_ptr. https://checkking.github.io/post/nginx/nginx4/ Fri, 24 Feb 2017 21:07:16 +0800 https://checkking.github.io/post/nginx/nginx4/ ngx_add_inherited_sockets 这个函数的目的是为了实现nginx平滑升级时获取原来的监听fd, 通过环境变量NGINX完成socket的继承，继承来的socket将会放到init_cycle的listening数组中。在NGINX环境变量中，每个socket中间用冒号或分号隔开。完成继承同时设置全局变量ngx_inherited为1。 相关代码： src/core/nginx.c static ngx_int_t ngx_add_inherited_sockets(ngx_cycle_t *cycle) { u_char *p, *v, *inherited; ngx_int_t s; ngx_listening_t *ls; inherited = (u_char *) getenv(NGINX_VAR); if (inherited == NULL) { return NGX_OK; } ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "using inherited sockets from \"%s\"", inherited); if (ngx_array_init(&cycle->listening, cycle->pool, 10, sizeof(ngx_listening_t)) != NGX_OK) { return NGX_ERROR; } for (p = inherited, v = p; *p; p++) { if (*p == ':' || *p == ';') { s = ngx_atoi(v, p - v); if (s == NGX_ERROR) { ngx_log_error(NGX_LOG_EMERG, cycle->log, 0, "invalid socket number \"%s\" in " NGINX_VAR " environment variable, ignoring the rest" " of the variable", v); break; } v = p + 1; ls = ngx_array_push(&cycle->listening); if (ls == NULL) { return NGX_ERROR; } ngx_memzero(ls, sizeof(ngx_listening_t)); ls->fd = (ngx_socket_t) s; } } ngx_inherited = 1; return ngx_set_inherited_sockets(cycle); } src/core/nginx. https://checkking.github.io/post/nginx/nginx2/ Sat, 18 Feb 2017 21:07:16 +0800 https://checkking.github.io/post/nginx/nginx2/ nginx的日志切分问题一直是运维nginx时需要重点关注的。本文将简单说明下nginx支持的两种日志切分方式。 定时任务切分 所谓的定时任务切分，是指通过定时任务（比如crontab)，发送信号给nginx，让其重新打开文件。该方法也是nginx官网上面比较推荐的,原文说明比较清楚，这里在说明下： 发送USR1 信号会让nginx主动重新打开日志文件，故操作如下： $ mv access.log access.log.0 $ kill -USR1 `cat master.nginx.pid` $ sleep 1 $ gzip access.log.0 # do something with access.log.0 总结 ：优点是思路较为简单，但效果明显，而且对error_log 同样适用；缺点是有外部依赖（比如 crontab) 自切分 自切分是指让nginx自身实现日志切分功能，不依赖crontab等东西。 其主要原理是依赖access_log的强大功能—- 可以用变量定义请求的log路径。 nginx的acess_log 功能非常强大，其完整指令说明如下，这里主要说明定义日志路径的功能；关于syslog还有gzip, buffer等特性，后续再说明。 access_log指令Syntax: access_log path [format [buffer=size [flush=time]] [if=condition]]; access_log path format gzip[=level] [buffer=size] [flush=time] [if=condition]; access_log syslog:server=address[,parameter=value] [format [if=condition]]; access_log off; 默认：access_log logs/access.log combined; Context: http, server, location, if in location, limit_except 注意path部分是支持nignx变量的，这也就意味这我们只要通过配置正确的nginx变量，就可以实现小时等级别的日志自动拆分了。 https://checkking.github.io/post/nginx/nginx1/ Mon, 13 Feb 2017 21:07:16 +0800 https://checkking.github.io/post/nginx/nginx1/ 运行中的Nginx进程间的关系 在正式提供服务的产品环境下，部署nginx都是使用一个master进程来管理多个worker进程， 一般情况下，worker进程的数量与服务器上的CPU核心数相等。 每个worker进程都是繁忙的，他们真正提供互联网服务，master进程则很清闲，只负责监控管理 worker进程。 Nginx是支持单进程(master进程)提供服务的，那么为什么产品环境下要按照master-worker方式配置同时 启动多个进程呢？这样做的好处主要有以下两点： - 由于master进程不会对用户请求提供服务，只用于管理真正提供服务的worker进程，所以master进程可以是唯一的，它仅专注于自己的纯管理工作，为管理员提供命令行服务，包括诸如启动服务、停止服务、重载配置文件、平滑升级程序等。master进程需要拥有较大的权限，例如，通常会利用root用户启动master进程。worker进程的权限要小于或等于master进程，这样master进程才可以完全地管理worker进程。当任意一个worker进程出现错误从而导致coredump时，master进程会立刻启动新的worker进程继续服务。 - 多个worker进程处理互联网请求不但可以提高服务的健壮性（一个worker进程出错后，其他worker进程仍然可以正常提供服务），最重要的是，这样可以充分利用现在常见的SMP多核架构，从而实现微观上真正的多核并发处理。因此，用一个进程（master进程）来处理互联网请求肯定是不合适的。另外，为什么要把worker进程数量设置得与CPU核心数量一致呢？这正是Nginx与Apache服务器的不同之处。在Apache上每个进程在一个时刻只处理一个请求，因此，如果希望Web服务器拥有并发处理的请求数更多，就要把Apache的进程或线程数设置得更多，通常会达到一台服务器拥有几百个工作进程，这样大量的进程间切换将带来无谓的系统资源消耗。而Nginx则不然，一个worker进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的worker进程之间处理并发请求时几乎没有同步锁的限制，worker进程通常不会进入睡眠状态，因此，当Nginx上的进程数与CPU核心数相等时（最好每一个worker进程都绑定特定的CPU核心），进程间切换的代价是最小的。 nginx配置相关 location模块中root和alias的区别 root方式的配置: location /download/ { root /opt/web/html/; } 如果请求的URI是/download/index/test.html，那么web服务器将会返回服务器上/otp/web/html/download/index/test.html文件的内容。 alias方式的配置: location /conf { alias /usr/local/nginx/conf; } 在URI向实际文件路径的映射过程中，已经把location后配置的/conf这部分字符串丢弃，因此，/conf/nginx.conf请求将根据alias path映射为 /usr/local/nginx/conf/nginx.conf (conf -> /usr/local/nginx/conf) root可以放置到http, server, location或if块中，而alias只能放置在location块中。 alias后面还可以添加正则表达式，例如： location .~ ^/test/(\w+)\.(\w+)$ { alias /usr/local/nginx/$2/$1.$2; } 这样，请求在访问/test/nginx.conf时，nginx会返回/usr/local/nginx/conf/nginx.conf文件中的内容。 try_files 语法： try_files path1 [path2] uri; 配置块： server、location try_files后要跟若干路径，如path1 path2…，而且最后必须要有uri参数，意义如下：尝试按照顺序访问每一个path,如果可以有效地读取，就直接返回这个path对应的文件结束请求，否则继续向下访问。如果所有path都找不到有效的文件，就重定向到最后的参数uri上。如： try_files /system/maintenance.html $uri $uri/index.html $uri.html @other; location @other { proxy_pass http://backend; } 文件操作的优化 sendfile 系统调用 语法: sendfile on|off; 默认：sendfile off; 配置快： http、server、location 可以启用Linux上的sendfile系统调用来发送文件，它减少了内核态与用户态之间的两次内存复制，这样就会从 磁盘中读取文件后直接在内核态发送到网卡设备，提高了发送文件的效率。 AIO系统调用 此配置项表示是否在FreeBSD或Linux上启用内核级别的异步文件I/O功能。注意，它与sendfile功能是互斥的。 directio 语法：directio size|off; 默认：directio off; 配置快： http、server、location 此配置项在FreeBSD和Linux系统上使用O_DIRECT选项去读取文件，缓冲区大小为size, 通常对大文件的读取速度有优化作用. https://checkking.github.io/post/nginx/nginx3/ Thu, 09 Feb 2017 21:07:16 +0800 https://checkking.github.io/post/nginx/nginx3/ location正则写法 一个示例： location = / { # 精确匹配 / ，主机名后面不能带任何字符串 [ configuration A ] } location / { # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求 # 但是正则和最长字符串会优先匹配 [ configuration B ] } location /documents/ { # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索 # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条 [ configuration C ] } location ~ /documents/Abc { # 匹配任何以 /documents/Abc 开头的地址，匹配符合以后，还要继续往下搜索 # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条 [ configuration CC ] } location ^~ /images/ { # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。 [ configuration D ] } location ~* \. https://checkking.github.io/post/cs/singals/ Thu, 09 Feb 2017 21:07:16 +0800 https://checkking.github.io/post/cs/singals/ 背景 最近在做一个实时日志监控系统，系统架构是filebeat+logstash+twisted, 其中filebeat用来监控日志文件的新增变动，logstash格式化日志，twisted作为server，接收logstash的输入, 实时计算ctr， server的统计数据要每小时持久化一次，也就是要写进mysql数据库中。但是在写入Mysql的过程中不影响server接收请求处理。因此想到的方案是在进入下一个小时的这一时刻fork一个进程，然后再子进程中 进行写入mysql操作。这种方案和redis写入快照的方案一样，因为twisted和redis都是基于事件的单进程单线程服务器模型, 利用fork的copy on write，保证在子进程中数据和父进程不会混乱。这种方案是work的。 但是twisted中用信号量有一点小问题，就是不能用SIGCHLD这个信号量来通知父进程子进程退出了, 最终无奈让子进程在退出前向父进程发送SIGUSR1自定义信号量, 父进程在收到这个信号量时改变状态参数。 之前对信号量处理上有些模糊的地方，想通过本篇博客总结一下。 什么是信号量 Unix信号是Unix系统的一种软件形式异常，一个信号就是一条消息，它通知进程系统中发生了一个某种类型的事件。在linux下输入”man 7 signal”就能得到Linux系统上支持的30中不同类型的信号。 Signal Value Action Comment SIGHUP 1 Term Hangup detected on controlling terminal or death of controlling process SIGINT 2 Term Interrupt from keyboard SIGQUIT 3 Core Quit from keyboard SIGILL 1 Term Hangup detected on controlling terminal or death of controlling process SIGINT 4 Core Illegal Instruction SIGABRT 6 Core Abort signal from abort(3) SIGFPE 8 Core Floating point exception SIGKILL 9 Term Kill signal SIGSEGV 11 Core Invalid memory reference SIGPIPE 13 Term Broken pipe: write to pipe with noreaders SIGALRM 14 Term Timer signal from alarm(2) SIGTERM 15 Term Termination signal SIGUSR1 30,10,16 Term User-defined signal 1 SIGUSR2 31,12,17 Term User-defined signal 2 SIGCHLD 20,17,18 Ign Child stopped or terminated SIGCONT 19,18,25 Cont Continue if stopped SIGSTOP 17,19,23 Stop Stop process SIGTSTP 18,20,24 Stop Stop typed at terminal SIGTTIN 21,21,26 Stop Terminal input for background process SIGTTOU 22,22,27 Stop Terminal output for background process 还有其他的没有列出来，可以自行查阅。信号提供了一种机制，通知用户进程发生了这些异常。 比如一个进程试图除以0，那么内核就发送给它一个SIGFPE信号。如果进程进行非法存储器引用，内核就发送一条 SIGSEGV信号， 当一个子进程终止或停止时，内核发送一个SIGCHLD信号给父进程。 https://checkking.github.io/post/cs/linux_useful_bash/ Tue, 07 Feb 2017 21:07:16 +0800 https://checkking.github.io/post/cs/linux_useful_bash/ 统计 统计当前目录下的所有文件行数： bash wc -l * 当前目录以及子目录的所有文件行数： bash find . * | xargs wc -l 统计目录以及子目录所有c文件行数： find . -name "*.c" | xargs wc -l 统计某小时中各分钟的请求个数: cat access.log | grep 3cf0266e | grep "16/Mar/2017:15" | awk '{print $4}' | awk -F':' '{sum[$3]++}END{for (i in sum) print i, sum[i]}' | sort -k1 正则统计某个字符串出现的次数: cat log | awk '{match($0, /(BASE_[_A-Z]+)/, a); cnt[a[1]]++} END{for (i in cnt) {print i"\t"cnt[i]}}' 查找与替换 查找当前目录下所有的文件包含某字符串 bash grep str * 查找包含某字符串的所有c++文件 https://checkking.github.io/post/arch/how_compute_big_file_lines/ Fri, 13 Jan 2017 21:07:16 +0800 https://checkking.github.io/post/arch/how_compute_big_file_lines/ 问题引入 昨天工作上有一个任务根据nginx日志做一些数据统计。由于日志文件很大，而且不断增大中。如果我要统计一小时以内的日志，这时候就没必要对所有日志都扫一遍。我的初步思路是先用wc -l统计一下日志行数，然后根据当前时间估算出平均每分钟产生了多少条日志。这样就可以估算一小时以内的日志条数了。然后用tail -n就可以了。 但是发现wc -l其实也是有点慢的。从gnu上把bash wc实现代码(http://mirrors.ustc.edu.cn/gnu/coreutils/coreutils-8.9.tar.gz)wget 下来看了。统计单个文件的内部实现是调用read(int filedes, char *buf, unsigned nbytes) 先把内容读入buffer，然后按字节统计，在实现上做了一些细节优化，性能还是很好的。 但是不管怎么样还是要对所有字节都扫一遍。有没有更好的方式呢？ 粗略统计文件行数 unix中struct state记录文件所有信息，但是没有文件行数，因此不能直接get到。 struct stat { dev_t st_dev; /* ID of device containing file */ ino_t st_ino; /* inode number */ mode_t st_mode; /* file type and mode */ nlink_t st_nlink; /* number of hard links */ uid_t st_uid; /* user ID of owner */ gid_t st_gid; /* group ID of owner */ dev_t st_rdev; /* device ID (if special file) */ off_t st_size; /* total size, in bytes */ blksize_t st_blksize; /* blocksize for filesystem I/O */ blkcnt_t st_blocks; /* number of 512B blocks allocated */ /* Since Linux 2. https://checkking.github.io/post/lang/cpp1/ Fri, 01 Jan 2016 21:07:16 +0800 https://checkking.github.io/post/lang/cpp1/ 为什么需要前向声明? 编译器确保在文件中使用的函数没有拼写错误或参数个数不对，因此它坚持要在使用函数之前要看到它的声明， 也就是为了方便编译器生成目标代码，不至于编译成功，运行的时候却失败。比如下面的例子： // file func.cpp #include <stdio.h> void func(int a, float b) { (void)a; (void)b; printf("func(int a, float b)\n"); } // file main.cpp #include <stdio.h> void func(int a, int b) { (void)a; (void)b; printf("func(int a, int b)\n"); } // void func(int a, float b); int main(int argc, char** argv) { func(1, 3.0f); return 0; } 我们本意想调用void func(int a, float b)，但是程序执行的时候却调用了void func(int a, int b)，这种错误 很难发现，因为在编译的时候没有报错。 如果我们把main.cpp改成下面的：