Server on Tech Explorer

用 process_vm_readv() 实现多进程内存队列

Thu, 04 Jun 2020 06:58:27 +0800

一，问题背景
#

多进程之间需要传输大量数据的时候，比如多进程 RPC 框架的进程之间通信，常用共享内存队列。

但是共享内存队列难免会有入队+出队 2次 memcpy 。

而且要变长共享内存队列，如果支持多生产者进程+多消费者进程，就要处理线程安全方面的问题，比较麻烦。

process_vm_readv() , process_vm_writev() 是 Linux 3.2 新增的 syscall，用于在多个进程的地址空间之间，高效传输大块数据。

https://www.man7.org/linux/man-pages/man2/process_vm_readv.2.html

https://github.com/open-mpi/ompi/blob/master/opal/mca/btl/sm/btl_sm_get.c#L96

在此，我提个设想，可以用 process_vm_readv 实现一个多进程内存队列，相比之下，优势是：

在处理多线程/多进程并发时，更简单
省掉一次 memcpy。

下面 demo 代码演示了这个思路。为了方便，直接用 posix mq 来传输 iovec 数组，也没有考虑多路复用。真实项目可能需要 eventfd 之内的机制来做 notify。

实测了下，3个进程加起来有 5.5 GB/秒的速度。

二，代码
#

#include <assert.h>
#include <fcntl.h>
#include <mqueue.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/uio.h>
#include <sys/wait.h>
#include <unistd.h>

#include <iostream>
#include <sstream>
#include <vector>
using namespace std;

struct MemMessage {
 pid_t pid = 0;
 vector<iovec> mem_vec;

public:
 MemMessage() {}

 string DebugString() const {
 ostringstream oss;
 oss << "pid=" << pid;
 for (const auto& mem : mem_vec) {
 oss << " iov={" << mem.iov_base << "," << mem.iov_len << "}";
 }
 return oss.str();
 }

 string ToString() const {
 pid_t from_pid = getpid();
 string buff;
 buff.append((const char*)&from_pid, sizeof(from_pid));
 for (const auto& mem : mem_vec) {
 buff.append((const char*)&mem, sizeof(mem));
 }
 return buff;
 }

 bool FromString(const char* buff, size_t buff_len) {
 size_t pos = 0;
 if (buff_len < sizeof(pid)) {
 return false;
 }
 pid = *((pid_t*)buff);
 pos += sizeof(pid);
 for (; pos + sizeof(iovec) <= buff_len; pos += sizeof(iovec)) {
 mem_vec.resize(mem_vec.size() + 1);
 auto& iov = mem_vec.back();
 memcpy(reinterpret_cast<char*>(&iov), buff + pos, sizeof(iov));
 }
 return true;
 }

 void CopyToMem(string& buff) {
 size_t sum = 0;
 for (const auto& iov : mem_vec) {
 sum += iov.iov_len;
 }

 buff.resize(sum, '\0');
 iovec local;
 local.iov_base = &buff[0];
 local.iov_len = buff.size();

 auto nread = process_vm_readv(pid, &local, 1, &mem_vec[0], mem_vec.size(), 0);
 // assert(nread >= 0);
 if (nread <= 0) {
 cout << getpid() << " process_vm_readv from=" << DebugString() << " sum=" << sum << " len=" << nread
 << endl;
 cout << "pid=" << pid << " " << strerror(errno) << endl;
 }
 }
};

class MemQueue {
 mqd_t m_mq;
 struct mq_attr m_attr;

public:
 int Init(const string& queue_name, bool read_write = false) {
 memset(&m_attr, 0, sizeof(m_attr));
 m_attr.mq_flags = 0;
 m_attr.mq_maxmsg = 10;
 m_attr.mq_msgsize = 4096;
 const int oflag = read_write ? O_WRONLY | O_CREAT : O_RDONLY;
 m_mq = mq_open(queue_name.c_str(), oflag, S_IRWXU, &m_attr);
 // m_mq = mq_open(queue_name.c_str(), oflag);
 cout << getpid() << " mq_open=" << queue_name << " oflag=" << oflag << " ret=" << m_mq << endl;
 }

 int PushMemMsg(const MemMessage& msg) {
 string buff = msg.ToString();
 return mq_send(m_mq, buff.c_str(), buff.size(), 0);
 }

 bool PopMemMsg(MemMessage& msg) {
 string buff(m_attr.mq_msgsize, '\0');
 unsigned prio = 0;
 const auto ret = mq_receive(m_mq, &buff[0], buff.size(), &prio);
 if (ret < 0) {
 return false;
 }
 buff.resize(ret);
 msg.FromString(buff.data(), buff.size());
 return true;
 }
};

const static string queue_name = "/test_queue";

enum STATUS { STATUS_WAITING = 0, STATUS_RUNNING = 1, STATUS_EXIT = 2 };

struct ControlCenter {
 int proc_status;
};

ControlCenter* control = nullptr;

void child_proc() {
 const auto ret = fork();
 assert(ret >= 0);
 if (ret != 0) {
 return;
 }

 while (STATUS_WAITING == control->proc_status) {
 usleep(1000);
 }

 MemQueue q;
 q.Init(queue_name);
 size_t bytes = 0;
 while (STATUS_RUNNING == control->proc_status) {
 MemMessage msg;
 if (q.PopMemMsg(msg)) {
 string buff;
 msg.CopyToMem(buff);
 bytes += buff.size();
 } else {
 usleep(1000);
 }
 }
 cout << getpid() << " bytes=" << bytes << " exit" << endl;

 exit(0);
}

int main(int argc, char* argv[]) {
 control = (ControlCenter*)mmap(NULL, sizeof(*control), PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);
 control->proc_status = STATUS_WAITING;

 const static int proc_num = 3;
 for (int i = 0; i < proc_num; ++i) {
 child_proc();
 }

 MemQueue q;
 q.Init(queue_name, true);

 control->proc_status = STATUS_RUNNING;
 string str(1024 * 1024 * 10, 'a');
 for (int i = 0; i < 10000; ++i) {
 MemMessage msg;
 for (int t = 0; t < 3; ++t) {
 size_t base = rand() % str.size();
 size_t size = rand() % (str.size() - base);
 msg.mem_vec.emplace_back(iovec{&str[base], size});
 }
 const auto ret = q.PushMemMsg(msg);
 // cout << getpid() << " PushMemMsg=" << msg.DebugString() << " ret=" << ret << endl;

 // sleep(1);
 }

 control->proc_status = STATUS_EXIT;

 for (int i = 0; i < proc_num; ++i) {
 int status = 0;
 wait(&status);
 }

 return 0;
}

构造最短程序打印自身的 MD5

Mon, 20 Apr 2020 00:00:00 +0000

一，介绍
#

比赛题目很简单：构造一个程序，在 stdout 上打印出自身的 MD5，程序越短越好。按最终程序文件大小字节数排名，文件越小，排名越靠前。只能使用 ld-linux-x86-64.so, libc.so, libdl.so, libgcc_s.so, libm.so, libstdc++.so 。禁止了 socket, shmget, fork, execvc 等 syscall 。

汇编高手如云，本人只做到 752 字节，只拿到 27 名。但忙活好几天，学到不少东西，也有苦劳，还是值得记录一下。

基本是纯 C 实现，没有动用汇编。

二，用过的一些思路和资源
#

基于这个 MD5 实现改造 https://gist.github.com/creationix/4710780

https://www.nayuki.io/page/fast-md5-hash-implementation-in-x86-assembly

参照 musl 和 rt0 ，去除对 glibc 依赖

musl libc https://www.musl-libc.org/
rt0 : https://github.com/lpsantil/rt0

三，没有成功的一些思路
#

思路，利用内核的 MD5 计算代码： grep -i md5 linux-5.6.2 只找到 2处，
1. TCP_MD5SIG ， CONFIG_TCP_MD5SIG : “TCP: MD5 Signature Option support (RFC2385)” 一个冷门特性，看起来通过 socket 才能执行。
2. AF_ALG Linux 的 crypto api，通过 socket 形式暴露 api，但是 socket 被禁用了。 https://www.chronox.de/libkcapi.html
构造碰撞，hardcode 直接 print 出来

https://github.com/corkami/collisions

https://www.rogdham.net/2017/03/12/gif-md5-hashquine.en

https://github.com/Rogdham/gif-md5-hashquine

http://www.win.tue.nl/hashclash/ 尝试了 fastcoll_v1 ，但是 fastcoll 构造1个字节的冲突要 2 block = 128 字节，则 16 字节就要 2048 字节，还不如 C 语言直接算。
通过某些 ipc 机制，绕过评判。试了简单的 shmget, 不成功。

三. 代码
#

后续借鉴思路，有优化

#define SYS_write 1
#define SYS_exit 60

inline long syscall3(long n, long a0, long a1, long a2) {
 long ret;
 __asm__ volatile("syscall" : "=a"(ret) : "a"(n), "D"(a0), "S"(a1), "d"(a2) : "rcx", "r11", "memory");
 return (ret);
}
inline long syscall1(long n, long a0) {
 long ret;
 __asm__ volatile("syscall" : "=a"(ret) : "a"(n), "D"(a0) : "rcx", "r11", "memory");
 return (ret);
}

static int write(int f, const char* d, int l) {
 int ret = syscall3(SYS_write, f, (long)(d), l);
 return (ret);
}

void _exit(int r) { syscall1(SYS_exit, r); }

typedef unsigned uint32_t;
typedef unsigned char uint8_t;
typedef unsigned long size_t;
#define NULL 0 // In words

#define memcpy(dest, src, n) \
 for (size_t i = 0; i < n; ++i) { \
 ((char*)dest)[i] = ((const char*)src)[i]; \
 }

// leftrotate function definition
#define LEFTROTATE(x, c) (((x) << (c)) | ((x) >> (32 - (c))))

static void md5_hash(uint8_t* initial_msg, const size_t initial_len, uint32_t hash[4]) {
 // Note: All variables are unsigned 32 bit and wrap modulo 2^32 when calculating

 // r specifies the per-round shift amounts
 const static uint8_t r[] = {
 7, 12, 17, 22, 5, 9, 14, 20, 4, 11, 16, 23, 6, 10, 15, 21,
 };

 // Use binary integer part of the sines of integers (in radians) as constants// Initialize variables:
 uint32_t k[64];
 for (int i = 0; i < 64; ++i) {
 double f = 1.0 + i;
 asm("fsin;\n\t"
 "fabs;\n\t"
 : "=t"(f)
 : "0"(f));
 f *= 4294967296.0;
 k[i] = (uint32_t)f;
 }

 // Pre-processing: adding a single 1 bit
 // append "1" bit to message
 /* Notice: the input bytes are considered as bits strings,
 where the first bit is the most significant bit of the byte.[37] */

 // Pre-processing: padding with zeros
 // append "0" bit until message length in bit ≡ 448 (mod 512)
 // append length mod (2 pow 64) to message

 const int new_len = ((((initial_len + 8) / 64) + 1) * 64) - 8;

 // Message (to prepare)
 uint8_t* msg = initial_msg msg[initial_len] = 128; // write the "1" bit

 uint32_t bits_len = 8 * initial_len; // note, we append the len
 memcpy(msg + new_len, &bits_len, 4); // in bits at the end of the buffer

 // Process the message in successive 512-bit chunks:
 // for each 512-bit chunk of message:
 for (int offset = 0; offset < new_len; offset += 64) {
 // break chunk into sixteen 32-bit words w[j], 0 ≤ j ≤ 15
 uint32_t* w = (uint32_t*)(msg + offset);

 // Initialize hash value for this chunk:
 uint32_t a = hash[0];
 uint32_t b = hash[1];
 uint32_t c = hash[2];
 uint32_t d = hash[3];

 // Main loop:
 uint32_t i;
 for (i = 0; i < 64; i++) {
 uint32_t f, g;

 if (i < 16) {
 f = (b & c) | ((~b) & d);
 g = i;
 } else if (i < 32) {
 f = (d & b) | ((~d) & c);
 g = (5 * i + 1) % 16;
 } else if (i < 48) {
 f = b ^ c ^ d;
 g = (3 * i + 5) % 16;
 } else {
 f = c ^ (b | (~d));
 g = (7 * i) % 16;
 }

 uint32_t temp = d;
 d = c;
 c = b;
 b = b + LEFTROTATE((a + f + k[i] + w[g]), r[i / 4 / 4 * 4 + i % 4]);
 a = temp;
 }

 // Add this chunk's hash to result so far:

 hash[0] += a;
 hash[1] += b;
 hash[2] += c;
 hash[3] += d;
 }
}

static char xdigits(char c) {
 if ((c >= 0) && (c <= 9)) {
 return '0' + c;
 }
 return 'a' + (c - 10);
}

void _start(void) __attribute__((noreturn));

void _start(void) {
 uint32_t hash[4] = {0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476};

 char* addr = (char*)0x400000;
 const size_t len = 688;
 md5_hash(addr, len, hash);

 unsigned char* md = (unsigned char*)&hash[0];
 char buff[32];
 for (int i = 0; i < 32; ++i) {
 unsigned x = md[(i >> 1)];
 x >>= (i & 1 ? 0 : 4);
 buff[i] = xdigits(x & 15);
 }
 write(1, &buff[0], sizeof(buff));
 _exit(0);
}

CFLAGS="-static -Os -Wl,--omagic -D__RT0_WITH_FASTER_SYSCALL__ -ffunction-sections -Wl,--gc-sections -nostartfiles -nodefaultlibs -nostdlib -nostdinc -Wl,--build-id=none -fomit-frame-pointer -fno-stack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-unroll-loops -fmerge-all-constants -fno-ident -mfpmath=sse -mfancy-math-387 -finline-functions-called-once -I ./ "

gcc $CFLAGS print_my_md5.c -S -fverbose-asm
gcc $CFLAGS print_my_md5.s -o print_my_md5 

strip -R .comment print_my_md5
strip -R .bss print_my_md5
ls -l ./print_my_md5
./ELFkickers/sstrip/sstrip print_my_md5
./print_my_md5
echo
md5sum ./print_my_md5
ls -l ./print_my_md5

基于 ElasticSearch 开发垂直搜索系统

Sun, 29 Mar 2020 00:00:00 +0000

一，背景介绍
#

ElasticSearch 是由 Lucene 包装上分布式复制一致性算法等附加功能，构成的开源搜索引擎系统。

近两年在业界热度大增，主要有 3 种应用场景：

全文搜索引擎
NOSQL 数据库
日志分析数据库 ELK

很多垂直领域搜索需求，都可以基于 ElasticSearch 来设计架构。

ElasticSearch 能大幅度提升相关业务的迭代开发速度，实现类似 sql 数据库增删改查一样的快速开发。并在相对高 qps 的在线业务中，保证毫秒级的延迟，提供极高的可用性和稳定性。

经过持续的研读官方文档，调研业界经验，并在实践中应用反思后，总结出一套架构方案。供参考，欢迎意见建议。

二，架构方案
#

一个 ElasticSearch 集群 cluster ，配套：

转发代理 proxy
队列

1. 转发代理 proxy
#

proxy 的功能是：

协议转换，做 rpc 协议如 protobuf 和 ElasticSearch REST json 之间的协议转换，对文档更新等请求，定义了 rpc 协议，便于队列做各种处理。
引入 RPC 框架成熟的负载均衡，容灾，故障屏蔽等功能，到对 ES 的 RPC 中，比如如果单机 ES 进程挂了，通过返回码让调用方自动换机器重试。
统一监控告警系统，监控各种请求失败，延迟分布等，并监控 ElasticSearch java 进程状态，集群状态
转发文档更新请求给本机的队列。用队列做削峰填谷，自动合并批量，做限流。
提供双写能力，便于索引升级切换
proxy 到本机 ES 做了 http 连接池，避免频繁的 HTTP tcp 建连接。

2. 队列
#

队列实现了出队限流，请求合并，削峰填谷 3个功能。

在实际业务中，常常会定期做文档全量更新，会出现短时间内写请求高峰，

如果直接写 ES，请求高峰时，经常出现 ES write 线程池占满，导致部分写请求失败。

另外部分业务每次请求只更新1个文档，导致 ES cpu 高，影响 ES 的写性能，不符合官方推荐做法。

为此，引入队列:

配置限制了出队的 QPS ，确保集中高峰被抹平，以匀速稳定地写入 ES，彻底消除了更新失败。
并用配置自动把多个请求合并成批量（比如 5000个文档一个批量），优化了 ES 的写入性能。
请求高峰中超出配置 QPS 的请求，队列自动暂存在文件中，随后处理，保证了 ES 服务平稳。

3. 其他工具
#

另外，繁荣的 ES 开源生态中，周边工具非常丰富便捷，我们常用的两种周边工具：kinana 和 bin/elasticsearch-sql-cli，极其方便快捷，大幅度提升了开发效率。

三，搜索应用开发优化指南
#

垂直搜索系统的在线检索部分，一般流程如下

ES 用来实现召回和粗排环节，和部分自动补全环节。

基于 ES 开发的优点：

ES/Lucene 的 Query DSL 极其强大全面灵活，业务逻辑代码大幅度简化，开发简单便捷，业务迭代开发速度大大提高。
有商业公司维护的高质量官方文档，网上也有海量资料，新人几天就可以上手，快速形成生产力，提升团队效率。
成熟稳定，就目前经验看没有遇到过 bug
业务如果扩展，后续伸缩性，扩展性，分 shard ，多副本等，都有比较成熟方案。

1. query DSL 语法
#

基于 ES 的开发，首先需要学习常见的几种 query，

ES 的 query 简单分成 4 类:

term query，对单个词的 query，包括 term/terms/range/exists/missing/ids/regexp 等
full text query ，全文检索query，对多个词（即句子）的query，包括 match/multi_match/common 等
compound query 复合 query，包括 bool/dis_max/function_score 等
match_all ，简单匹配所有文档

建议先学习 term/match/range/bool ，就可以实现大部分业务逻辑。

网上资料较多，就不转述了。

可以先看看这些中文资料，在 test 环境的 kibana 做做实验，快速上手：

https://www.elastic.co/guide/cn/elasticsearch/guide/current/search-in-depth.html

https://my.oschina.net/yumg/blog/637409

https://www.cnblogs.com/yjf512/p/4897294.html

当然最好的还是官方英文文档：

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html

2. 分词
#

中文搜索的一个核心议题，就是分词。

ElasticSearch 常用的中文分词是 ik analyzer。ik 是开箱即用，便于小型业务快速开发的。

但是作为对分词可定制性要求较高的业务，我们实际测试，发现 ik analyzer :

不支持本地自定义词典文件的热加载；
无法针对不同 index 配置不同自定义词典；
另外对一些分词的 bad case ，比如没有正确切分的词，没法简单 fix。

因此推荐不用 ik ，而是在更新文档和搜索的时候，在外部做分词，然后用空格拼起来，传给 ES 做索引/搜索。这种方案中，在 ES mapping 中配置成 whitespace 分词器。

外部分词可以用 cppjieba 等，索引分词还可以合并多种分词算法结果提高召回率。

对 cppjieba ，我之前做过内存优化，将内存优化到了 1/100。

另外，索引之前，也有必要做 UTF8 的 normalize，全角转半角，英文大小写统一，和英文的词干提取， mapping 中常用

"cjk_width", "lowercase", "porter_stem"

这些filter

具体可以参考已有业务代码。

3.关系型搜索
#

实际开发遇到典型的 one-many 关系型数据上的 query，

比如在某业务中，就遇到这种逻辑，经过调研发现常见有 4 种方案：

分开2 个 index : one + many ，分开2次串行 search，问题: 需要2次延迟大
反范式，完全展开，one 的数据追加到每一个 many 文档中，问题：数据量变大，更新 one 需要用 _update_by_query 如果 one 数据更新频繁，可能导致大量写操作
nested ，比如 one 嵌套 many 子文档问题是：nested 嵌套文档更新需要更新整个 root 文档，即要把整个 one 文档和含有的 many 文档 select 出来，修改，再写回。对热门 one 文档，更新会操作大量数据，并发写还可能 data race。
join, has_parent, has_child 把 one 和 many 的所有字段合并到一个 index 中， one 和 many 分别独立更新。

经过实际数据测试 join field 方案，发现当 one:many = 1:1000万时，延迟在 5ms 可以接受，因此目前采用了这种方案。

当然，官方文档指出 join 性能是会慢的，后续也有待实践检验。

4. 粗排相关性打分
#

Lucene 从 2016年的 6.0 版本开始，默认的相关性算法切换成了 bm25 ， bm25 是一种调整过的 tf idf 算法。

这里可以做一简单举例介绍，更深入的介绍可以参见下面文章，以及官方文档：

https://farer.org/2018/09/10/practical-bm25-part-1-how-shards-affect-relevance-scoring-in-elasticsearch/

https://www.cnblogs.com/richaaaard/p/5254988.html

ES 的 explain 对 bm25 算分的过程有详尽的解释，推荐自行实验。

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-explain.html

4.1. BM25 例解
#

比如某业务的真实数据中，我们在所有文档的 title 这个 field 搜索 “牛奶 ” 这个词，

explain 可以看到，这个 bm25 分数的是这样得来的：

sum( weight(title:牛奶 in 77341) [PerFieldSimilarity] ) ，
weight(title:牛奶 in 77341) [PerFieldSimilarity] = idf * tfNorm

首先，如果某 field 被多个 term 命中，分别算每个 term 的分数 (PerFieldSimilarity)，然后求和，本例子只有1个 term “牛奶”。

每个 term 的分数 PerFieldSimilarity

PerFieldSimilarity = idf * tfNorm

而 idf 表征词的重要程度，与具体文档无关。

idf = log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5))

其中 docFreq 就是本shard 中，有多少个文档含有 “牛奶”， docCount 就是本shard 一共有多少个文档。

tfNorm = (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength))
termFreq=1.0
k1=1.2
b=0.75
avgFieldLength=14.456173
fieldLength=2 //比如如果 title 是 "牛奶 醪糟" ，那就是 2个 term

freq 即该 field 中，“牛奶”这个词出现了几次 k1 和 b 都是固定常数。 fieldLength 是当前文档的当前field ，一共有多少个 term。 avgFieldLength 即本 shard 中的所有文档的本 field 的 fieldLength 的平均值

4.2. BM25 shard 调整
#

实际业务发现，当 index 内文档太少(比如 10w 量级就算少) 时，有的词在多个 shard 内，词频分布会出现严重不均匀，可能会导致 bm25 分数产生较大偏差，

实践中的解决办法：

Search 的 url_parameters 参数填 “&search_type=dfs_query_then_fetch”
减少 shard 数

4.3. BM25 similarity 参数调整
#

如上计算过程可见，bm25 中的 b 参数，是用来给短文档做加权的，即 b 越大，越倾向于给短文档更高的 score，实际中，和算法同学一起分析后，发现针对我们的某业务，不应该对短文本有太高偏向，所以我们把 b 调整成了 0.3 ，实测发现解决了一批 bad case，用户体验有明显改善。

四，性能优化
#

计算机程序的性能取决于数据结构和算法， ES/Lucene 中主要有几种数据结构:

FST
Posting List ，著名的倒排索引，PForDelta 压缩，支持 SkipList 方式跳跃
BKD Tree，用来实现 int 和 geo 查询
DocValues , 以 DocID 为 Key 的列存储

https://zhuanlan.zhihu.com/p/47951652

https://www.elastic.co/blog/elasticsearch-query-execution-order

更深入的理解，我目前也在探索中。

在垂直搜索引擎业务中，用户对延迟非常敏感，一般业界经验认为，良好的用户体验应该是在 ** 200毫秒 ** 内返回搜索结果，这就意味着 ES 延迟最好控制在 100毫秒之内。

经过我们实际业务发现，决定 ES 延迟的因素主要有：

内存是否足够， page cache 是否 cache 了检索过程用到的文件数据
具体 query 的优化，类比 mysql query 优化

1. page cache 内存优化
#

page cache 是决定 ES 延迟的首要因素，用作在线检索服务的 ES ，实际中在线检索的代码路径不能有硬盘 io 访问 (实践证明， SSD也不行)

当 ES 用作在线垂直搜索引擎时，

《查询亿级数据毫秒级返回！牛逼哄哄的ElasticSearch是如何做到的？》 https://zhuanlan.zhihu.com/p/68706615

《ElasticSearch在数十亿级别数据下，如何提高查询效率？》 https://zhuanlan.zhihu.com/p/60458049

实践中，某 index 发现延迟非常高，达到了 1-2秒，用户体验很差。调查发现，iostat 看下 io util 很高，经常到 80% 90%，单机索引数据文件是 page cache 可用内存的 4倍，于是降低了副本数，单机数据量减少到 page cache 可用内存2倍后，硬盘 io 降到了 0 ，延迟一下降低到了 150ms 。

2. int 字段查询优化
#

业务中常会有一些 int 型的字段，存一些枚举性质的值。在 10亿以上文档的情况下，实际发现有的会出性能问题。

比如比如前述业务有1个 int 类型的 filter 字段，实际只有 {0,1} 2种取值，

借助 ES 的 profile ，我们发现搜索 query 93% 的耗时在 filter 字段的 PointInSetQuery 中，

随后发现，针对该业务，只需要返回 filter 为 0 的文档，于是我们在更新文档时，发现 filter 非0 的文档，直接把所有字段都清空，并随后在 query 中去掉了 filter 字段的过滤。

之后发现耗时从 150ms 降到了 20ms。

3. 副本数 replicas num
#

确定副本数的思路：

副本数越小越好。越小，单机数据越少，文件被 cache 的比例越高，性能越好。
副本太少会影响可用性。因此必须大于最大能容忍故障单机个数 max_failures 。

综合起来就是：

max(max_failures, ceil(num_nodes / num_primaries) - 1).

num_primaries 是 primary shards 的数量，就是一个 index 有多少个 shards，一般都 > num_nodes

replicas_might_help_with_throughput_but_not_always

对数据量特别少的 index，可以每台机都存一个副本 “auto_expand_replicas”: “0-all”,

4. 多 SSD
#

在 elasticsearc.yml 的 path.data 配置多个路径，ES 会自动把 shard 均分到多个路径上，如果有多个硬盘，可以充分利用多设备的 io 带宽，当然对在线业务意义不大。

5. 内存配置
#

最开始我们使用 16G 内存机型，后来发现出现大量 Elasticsearch Data too large Error 错误，随后发现，解决办法就是换到 64G 内存机型，

改 jvm.options 加大 jvm 的 heap 解决，从 10G 加大到 30G 解决 -Xms30g -Xmx30g

需要注意的是，不建议大于 32G，避免 jvm 的指针压缩优化失效。可以看 ES 的启动 log 确定

[2019-05-22T12:29:16,961][INFO ][o.e.e.NodeEnvironment ] [node_xxx] heap size [29.7gb], compressed ordinary object pointers [true]

https://www.elastic.co/cn/blog/a-heap-of-trouble

6. refresh_interval
#

如网上众多文章所说， refresh_interval 一般都设成了 30秒。

一些参考资料：

滴滴 Elasticsearch 多集群架构实践 https://cloud.tencent.com/developer/article/1405404
京东到家订单中心 Elasticsearch 演进历程 https://cloud.tencent.com/developer/article/1377194
从平台到中台：Elaticsearch在蚂蚁金服的实践经验 https://new.qq.com/omn/20190117/20190117A09ADY.html
美团点评旅游搜索召回策略的演进 https://tech.meituan.com/2017/06/16/travel-search-strategy.html
eBay 的 Elasticsearch 性能调优实践 https://www.infoq.cn/article/elasticsearch-performance-tuning-practice-at-ebay
有赞搜索系统的架构演进 https://tech.youzan.com/search-tech-1/
有赞搜索引擎实践(工程篇) https://tech.youzan.com/search-engine1/
全面理解搜索Query：当你在搜索引擎中敲下回车后，发生了什么？ https://zhuanlan.zhihu.com/p/112719984
elasticsearch初学终极教程: 从零到一 https://kalasearch.cn/blog/elasticsearch-tutorial/

pdqsort-qsort

Tue, 03 Mar 2020 00:00:00 +0000

可以对抗输入数据模式的排序算法。

quick sort 在输入数据接近有序的情况下，效率不高。

Pattern-defeating quicksort (pdqsort) is a novel sorting algorithm that combines the fast average case of randomized quicksort with the fast worst case of heapsort, while achieving linear time on inputs with certain patterns. pdqsort is an extension and improvement of David Mussers introsort. All code is available for free under the zlib license.

pdqsort 结合了随机化的 quicksort 的快速的平均性能，和 heapsort 在最坏情况下的性能，并且在某些特定的输入模式下，可以实现线性的性能。 pdqsort 是 David Mussers 的 introsort 的一个扩展。

https://github.com/orlp/pdqsort

Single Thread Algorithms This table provides a brief description of the single thread algorithms of the library.

ClickHouse/contrib/pdqsort/

https://www.boost.org/doc/libs/1_67_0/libs/sort/doc/html/sort/single_thread.html

Algorithm	Stable	Additional memory	Best, average, and worst case	method
spreadsort	no	key_length	N, Nsqrt(LogN), min(NlogN, Nkey_length)	Hybrid radix sort
pdqsort	no	Log N	N, NLogN, NLogN	Comparison operator
spinsort	yes	N / 2	N, NLogN, NLogN	Comparison operator
flat_stable_sort	yes	size of the data / 256 + 8K	N, NLogN, NLogN	Comparison operator

spreadsort is an extremely fast hybrid radix sort algorithm, designed and developed by Steven Ross.
pdqsort is a improvement of the quick sort algorithm, designed and developed by Orson Peters.
spinsort is a stable sort that is fast with random or nearly sorted data, designed and developed by Francisco Tapia.
flat_stable_sort is a stable sort that uses very little additional memory (around 1% of the size of the data), providing 80% - 90% of the speed of spinsort, designed and developed by Francisco Tapia.

用 abstract unix socket 实现进程单实例运行

Tue, 03 Mar 2020 00:00:00 +0000

一，问题背景
#

很多时候，我们需要确保进程只有一个实例运行。

有几种方法：

http://stackoverflow.com/questions/2964391/preventing-multiple-process-instances-on-linux

http://stackoverflow.com/questions/5339200/how-to-create-a-single-instance-application-in-c-or-c

https://github.com/qtproject/qt-solutions/tree/master/qtsingleapplication/src

比较常规的做法，是对一个文件加文件锁 flock，比如对 pid 文件 flock( LOCK_EX|LOCK_NB )

但是这种方法有些弊端：

如果文件被 mv 或者 rm，是会被绕过的。
如果磁盘故障比如磁盘满，目录没有写权限，会失败。

二，abstract namespace unix socket
#

http://linux.die.net/man/7/unix

unix socket 有3种：

基于文件的
socketpair 创建的，匿名的
abstract namespace 的，Linux特有

Linux 下， AF_UNIX socket 支持一种特殊的 abstract namespace unix socket 。

相比普通的基于文件系统的 unix socket，abstract namespace unix socket ：

没有磁盘文件
进程挂了以后自动删除，无残留文件
无需担心与文件系统上的文件冲突，不需要关心文件系统上的绝对路径是否存在的问题

在 lsof 的结果里面看起来，就是有一些类似 @test_abstract_ns 这样的文件项

代码中使用也很简单， abstract namespace unix socket 在 bind 之前，sockaddr_un.sun_path[0] 设成 0x0 即可。

三，代码
#

于是我用 abstract unix socket 实现了一个 SysSem 工具类（一个 system 范围的 semaphore ），用来：

让一个程序只启动一个实例。
让 x 进程等待 y 进程执行完 yyy 操作后，才能执行 xxx 操作。

特点：

多进程/线程并发安全。
当持有的进程被 kill ，OS自动释放，无残留。
没有磁盘文件，没有文件意外被删的各种情况。
不占用 tcp/udp 端口。
简单，不到 60行代码。

#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>

#include <algorithm>
#include <string>

//
// a semaphore with system scope.
//
// 1. no race conditions between Post() / GetValue() , better than flock().
// 2. when a running process be killed, automatically release all.
// 3. no file on disk, no accidently delete .
// 4. no tcp/udp socket, no confliction, no port consumption.
//
class SysSem {
public:
 SysSem() : _fd(-1) { memset(&_addr, 0, sizeof(_addr)); }
 ~SysSem();

 void Init(std::string id);

 bool Post();
 bool GetValue();

 const char* GetID() const;

private:
 struct sockaddr_un _addr;
 int _fd;
};

void SysSem::Init(std::string id) {
 _addr.sun_family = AF_UNIX;
 const size_t len = std::min(id.size(), sizeof(_addr.sun_path) - 2); // 2 = start null and end null byte
 // abstract namespace socket address , _addr.sun_path[0] is a null byte ('\0')
 memcpy(_addr.sun_path + 1, id.c_str(), len);
 // memcpy(_addr.sun_path + 0, id.c_str(), len);
}

const char* SysSem::GetID() const { return &_addr.sun_path[1]; }

SysSem::~SysSem() {
 if (_fd >= 0) {
 ::close(_fd);
 _fd = -1;
 }
}

bool SysSem::Post() {
 _fd = ::socket(AF_UNIX, SOCK_STREAM, 0);
 if (_fd < 0) {
 return false;
 }

 if ((0 != ::bind(_fd, (struct sockaddr*)&_addr, sizeof(_addr))) || (0 != listen(_fd, 65536))) {
 return false;
 }
 return true;
}

bool SysSem::GetValue() {
 const int clientFD = ::socket(AF_UNIX, SOCK_STREAM, 0);
 if (clientFD < 0) {
 return false;
 }
 const bool ret = (0 == ::connect(clientFD, (struct sockaddr*)&_addr, sizeof(_addr)));
 ::close(clientFD);
 return ret;
}

#include <assert.h>
#include <stdio.h>

int main(int argc, char** argv) {
 if (argc != 3) {
 fprintf(stderr, "usage: %s abstract-path post/get\n", argv[0]);
 exit(1);
 }

 SysSem inst;
 inst.Init(argv[1]);

 if (0 == strcasecmp(argv[2], "post")) {
 assert(inst.Post());
 SysSem check;
 check.Init(argv[1]);
 assert(check.GetValue());
 printf("ok, i am the only one under %s. running ...\n", inst.GetID());
 pause();

 } else if (0 == strcasecmp(argv[2], "get")) {
 assert(inst.GetValue());
 printf("a process is running under %s. \n", inst.GetID());
 } else {
 printf("unknown cmd \n");
 }

 return 0;
}

Python 自动翻译成 C++ ，彻底保证离线在线特征一致

Fri, 29 Nov 2019 00:00:00 +0000

一，问题背景
#

随着深度学习的广泛应用，在搜索引擎/推荐系统/机器视觉等业务系统中，越来越多的深度学习模型部署到线上服务。

机器学习模型在离线训练时，一般要将输入的数据做特征工程预处理，再输入模型在 TensorFlow PyTorch 等框架上做训练。

1.常见的特征工程逻辑
#

常见的特征工程逻辑有：

分箱/分桶离散化
log/exp 对数/幂等 math numpy 常见数学运算
特征缩放/归一化/截断
交叉特征生成
分词匹配程度计算
字符串分隔匹配判断tong
缺省值填充等
数据平滑
onehot 编码，hash 编码等

这些特征工程代码，当然一般使用深度学习最主要的语言 python 实现。

二，业务痛点
#

离线训练完成，模型上线部署后，同样要用 C++ 重新实现 这些 python 的特征工程逻辑代码。

我们发现，“用 C++ 重新实现” 这个步骤，给实际业务带来了大量的问题：

繁琐，费时费力，极容易出现 python 和 C++ 代码不一致
不一致会直接影响模型在线上的效果，导致大盘业务指标不如预期，产生各种 bad case
不一致难以发现，无法测试，无法监控，经常要靠用户投诉反馈，甚至大盘数据异常才能发现

1. 业界方案
#

针对这些问题，我调研了这些业界方案：

《推荐系统中模型训练及使用流程的标准化》 https://www.infoq.cn/article/2E6LCqb1GeqFRAjkkjX3

《自主研发、不断总结经验，美团搜索推荐机器学习平台》 https://cloud.tencent.com/developer/article/1357309

《京东电商推荐系统实践》 https://www.infoq.cn/article/1OkKmb_gEYNR3YqC9RcW

“模型线上线下一致性问题对于模型效果非常重要，我们使用特征日志来实时记录特征，保证特征的一致性。这样离线处理的时候会把实时的用户反馈，和特征日志做一个结合生成训练样本，然后更新到模型训练平台上，平台更新之后在推送到线上，这样整个排序形成了一个闭环。”

总结起来，有几种思路：

在线特征存储起来给离线用
在线 C++ 代码编译成 so 导出给离线用
根据一份配置生成离线和在线代码
提取公共代码，加强代码复用，等软件工程手段，减少不一致

2. 自动翻译方案
#

(1) .已有方案的缺点
#

但这些思路都有各种缺点：

所有在线请求的所有特征，这个存储量数据量很大
算法改代码需要等待后台开发，降低了算法同学的工作效率
特征处理代码的复杂度转移到配置文件中，不一定能充分表达，而且配置格式增加学习成本
就这边真实离线特征处理代码来看，大部分代码都无法抽取出公共代码做复用。

(2). 翻译器
#

回到问题出发点考虑，显而易见，这个问题归根结底就是需要一个 “ python 到 c++ 的翻译器 ” 。

那其实 “翻译器 Transpiler ” ，和编译器解释器类似，也是个古老的热门话题了，比如 WebAssembly, CoffeeScript ，Babel , Google Closure Compiler，f2c

于是一番搜索，发现 python 到 C++ 的翻译器也不少，其中 Pythran 是新兴比较热门的开源项目。

于是一番尝试后，借助 pythran，我们实现了：

一条命令 全自动把 Python 翻译成等价 C++
严格等价保证改写，彻底消除不一致
完全去掉重新实现 这块工作量，后台开发成本降到 0 ，彻底解放生产力
算法同学继续使用纯 python，开发效率无影响，** 无学习成本 **
并能推广到其他需要 python 改写成后台 C++ 代码 的业务场景，解放生产力

三，pythran 的使用流程
#

(1). 安装
#

一条命令安装：

pip3 install pythran

(2). 写 Python 代码
#

下面这个 python demo，是 pythran 官方 demo

import math
import numpy as np

def zero(n, m):
 return [[0]*n for col in range(m)]

#pythran export matrix_multiply(float list list, float list list)
def matrix_multiply(m0, m1):
 new_matrix = zero(len(m0),len(m1[0]))
 for i in range(len(m0)):
 for j in range(len(m1[0])):
 for k in range(len(m1)):
 new_matrix[i][j] += m0[i][k]*m1[k][j]
 return new_matrix

#pythran export arc_distance(float[], float[], float[], float[])
def arc_distance(theta_1, phi_1, theta_2, phi_2):
 """
 Calculates the pairwise arc distance
 between all points in vector a and b.
 """
 temp = (np.sin((theta_2-theta_1)/2)**2
 + np.cos(theta_1)*np.cos(theta_2) * np.sin((phi_2-phi_1)/2)**2)
 distance_matrix = 2 * np.arctan2(np.sqrt(temp), np.sqrt(1-temp))
 return distance_matrix


#pythran export dprod(int list, int list)
def dprod(l0,l1):
 """WoW, generator expression, zip and sum."""
 return sum(x * y for x, y in zip(l0, l1))


#pythran export get_age(int )
def get_age(age):
 if age <= 20:
 age_x = '0_20'
 elif age <= 25:
 age_x = '21_25'
 elif age <= 30:
 age_x = '26_30'
 elif age <= 35:
 age_x = '31_35'
 elif age <= 40:
 age_x = '36_40'
 elif age <= 45:
 age_x = '41_45'
 elif age <= 50:
 age_x = '46_50'
 else:
 age_x = '50+'
 return age_x

(3). Python 转成 C++
#

一条命令完成翻译

pythran -e demo.py -o demo.hpp

(4). 写 C++ 代码调用
#

pythran/pythonic/ 目录下是 python 标准库的 C++ 等价实现，翻译出来的C++ 代码需要 include 这些头文件

写个 C++ 代码调用

#include "demo.hpp"
#include "pythonic/numpy/random/rand.hpp"
#include <iostream>

using std::cout;
using std::endl;

int main() {
 pythonic::types::list<pythonic::types::list<double>> m0 = { {2.0, 3.0},
 {4.0, 5.0} },
 m1 = { {1.0, 2.0},
 {3.0, 4.0} };
 cout << m0 << "*" << m1 << "\n=\n"
 << __pythran_demo::matrix_multiply()(m0, m1) << endl
 << endl;

 auto theta_1 = pythonic::numpy::random::rand(3),
 phi_1 = pythonic::numpy::random::rand(3),
 theta_2 = pythonic::numpy::random::rand(3),
 phi_2 = pythonic::numpy::random::rand(3);
 cout << "arc_distance " << theta_1 << "," << phi_1 << "," << theta_2 << ","
 << phi_2 << "\n=\n"
 << __pythran_demo::arc_distance()(theta_1, phi_1, theta_2, phi_2) << endl
 << endl;

 pythonic::types::list<int> l0 = {2, 3}, l1 = {4, 5};
 cout << "dprod " << l0 << "," << l1 << "\n=\n"
 << __pythran_demo::dprod()(l0, l1) << endl
 << endl;

 cout << "get_age 30 = " << __pythran_demo::get_age()(30) << endl << endl;

 return 0;
}

(5). 编译运行
#

g++ -g -std=c++11 main.cpp -fopenmp -march=native -DUSE_XSIMD -I /usr/local/lib/python3.6/site-packages/pythran/ -o pythran_demo 

./pythran_demo

四，pythran 的功能与特性
#

(1). 介绍
#

按官方定义，Pythran 是一个 AOT (Ahead-Of-Time - 预先编译) 编译器。给科学计算的 python 加注解后，pythran 可以把 python 代码变成接口相同的原生 python 模块，大幅度提升性能。

并且 pythran 也可以利用 OpenMP 多核和 SIMD 指令集。

支持 python 3 和 Python 2.7 。

pythran 的 manual 挺详细： https://pythran.readthedocs.io/en/latest/MANUAL.html

(2). 功能
#

pythran 并不支持完整的python，只支持 python 语言特性的一个子集:

polymorphic functions 多态函数(翻译成 C++ 的泛型模板函数)
lambda
list comprehension 列表推导式
map, reduce 等函数
dictionary, set, list 等数据结构
exceptions 异常
file handling 文件处理
部分 numpy

不支持的功能：

classes 类
polymorphic variables 可变类型变量

(3). 支持的数据类型和函数
#

pythran export 可以导出函数和全局变量。支持导出的数据类型，BNF 定义是：

 argument_type = basic_type
 | (argument_type+) # this is a tuple
 | argument_type list # this is a list
 | argument_type set # this is a set
 | argument_type []+ # this is a ndarray, C-style
 | argument_type [::]+ # this is a strided ndarray
 | argument_type [:,...,:]+ # this is a ndarray, Cython style
 | argument_type [:,...,3]+ # this is a ndarray, some dimension fixed
 | argument_type:argument_type dict # this is a dictionary

 basic_type = bool | byte | int | float | str | None | slice
 | uint8 | uint16 | uint32 | uint64 | uintp
 | int8 | int16 | int32 | int64 | intp
 | float32 | float64 | float128
 | complex64 | complex128 | complex256

可以看到基础类型相当全面，支持各种整数，浮点数，字符串，复数

复合类型支持 tuple, list, set, dict, numpy.ndarray 等，

对应 C++ 代码的类型实现在 pythran/pythonic/include/types/ 下面，可以看到比如 dict 实际就是封装了一下 std::unordered_map https://pythran.readthedocs.io/en/latest/SUPPORT.html 可以看到支持的 python 基础库，其中常用于机器学习的 numpy 支持算比较完善。

五，pythran 的基本原理
#

和常见的编译器/解释器类似， pythran 的架构是分成 3 层：

python 代码解析成抽象语法树 AST 。用 python 标准库自带的的 ast 模块实现
代码优化。在 AST 上做优化，有多种 transformation pass，比如 deadcode_elimination 死代码消除，loop_full_unrolling 循环展开等。还有 Function/Module/Node 级别的 Analysis，用来遍历 AST 供 transformation 利用。
后端，实现代码生成。目前有2个后端，Cxx / Python， Cxx 后端可以把 AST 转成 C++ 代码（ Python 后端用来调试）。

目前看起来，pythran 还欠缺的：

字符串处理能力欠缺，缺少 str.encode()/str.decode() 对 utf8 的支持
缺少正则表达式 regex 支持
缺少 json 支持

看文档要自己加也不麻烦，看业务需要可以加。

六，相关文章
#

《京东电商推荐系统实践》 https://www.infoq.cn/article/1OkKmb_gEYNR3YqC9RcW

《自主研发、不断总结经验，美团搜索推荐机器学习平台》 https://cloud.tencent.com/developer/article/1357309

《推荐系统中模型训练及使用流程的标准化》 https://www.infoq.cn/article/2E6LCqb1GeqFRAjkkjX3

numba http://numba.pydata.org

用 DAT 重实现 CppJieba 中文分词算法，降低 99% 内存消耗

Mon, 25 Nov 2019 00:00:00 +0000

一，问题背景
#

中文分词应用比较广泛的开源算法，是 jieba 结巴分词，结巴分词较高性能的实现是 C++ 版本的 CppJieba : https://github.com/yanyiwu/cppjieba

在实际使用 CppJieba 的过程中，我们发现 CppJieba 的内存占用比较高。

比如对一个 76W 词大小 11MB 的词典，加载 2份（比如为了支持平滑改动用户词典）就需要耗费 505MB内存。

这对一些多进程的后台服务，浪费大量内存，难以接受，因此这里希望削减内存耗费。

经过初步调查，确定改进方法，然后动手改造，最终把 505MB 缩减到了 4.7MB ，实现了 99% 内存降低。

此处也有 issue 讨论 https://github.com/yanyiwu/cppjieba/issues/3

代码在 https://github.com/byronhe/cppjieba 。

二，实现过程
#

二.1 查内存分布
#

第一步先用 jemalloc 的 memory profiler 工具查看内存耗费在哪里，

改一下 CppJieba 的 test/demo.cpp，链接 jemalloc，编译成二进制 jieba_test
然后设置环境变量 export MALLOC_CONF="prof:true,prof_prefix:mem_prof/mem_profile_je.out,lg_prof_interval:20,lg_prof_sample:20"
然后 mkdir mem_prof，并运行测试程序
jeprof –pdf ./jieba_test mem_prof/mem_profile_je.out.xxx.heap > mem_profile.pdf

打开 mem_profile.pdf ，就可以看到内存分布了

二.2 优化方案
#

显而易见，内存主要耗费在:

Trie.hpp 中的 Trie 树构建
KeywordExtractor.hpp 加载 idf 词典文件。

因此方案:

1. Double Array Trie 代替 cppjieba::Trie
#

引入 Double Array Trie (简称 DAT ,https://github.com/s-yata/darts-clone) , 代替 Trie.hpp 中的简单内存 Trie，并把 darts 生成的 DAT 保存到文件中，在启动时，如果已经有和词典对应的 DAT ，直接 mmap() attach 上去，即可启动。

经过实测发现，75万词词典，dart-clone 生成的 DAT 文件，大小只有 24MB，而且可以 mmap 挂载，多进程共享。

2. KeywordExtractor
#

KeywordExtractor 是个不常用功能，直接改成支持传入空的 idfPath 和 stopWordPath, 此时不加载数据即可。

二.3 其他问题
#

1. 支持热更新，保证词典和DAT一致
#

这里一个问题是，词典可能热更新，那怎么知道 DAT 文件和当前词典的内容对应？

我的做法是，对默认词典文件+自定义词典文件，用文件内容算 MD5，写入 DAT 文件头部，这样打开 DAT 文件发现 MD5 不一致，就知道 DAT文件过时了，即可重建 DAT 。

实测发现算 MD5 还是很快的，启动时间都在 1秒左右。

2. 代码清理
#

另外，清理了一下代码，删掉了 Unicode.hpp 中的无用代码。清理了 FullSegment.hpp HMMSegment.hpp MixSegment.hpp MPSegment.hpp QuerySegment.hpp 等中的重复代码。

3. 不兼容改动
#

由于 Double Array Trie 无法支持动态插入词，删除 InsertUserWord() 方法
FullSegment.hpp 中 maxId 的计算有 bug，做了 fix。
为了节省内存，改成允许传入空的 idfPath 和 stopWordPath 。
会生成 Double Array Trie 临时文件，临时文件名默认会自动生成，也可以传 dict_cache_path 指定
改成自定义词典中重复的词，保留权重最大的。
删除 Unicode.hpp 中的无用代码

整体改造后，代码量比原来减少 100 多行。

上线后效果显著。

当内存降低到 2-3MB 的水平后，这意味着 75W 词这种规模的大词典，可以用在手机环境。

比如可以在 ios 或者 Android 上做中文/英文的切词，这意味着可能在客户端实现体验相当良好的搜索引擎。

ios 上也有可用于中文的分词器 CFStringTokenizer ，但貌似不开源。

GB 规模语料上的高性能新词发现算法

Wed, 18 Sep 2019 00:00:00 +0000

分词是中文搜索的重要环节，目前分词算法已经比较成熟，分词错误的主要是由于未登录词。

因此发现业务领域语料库中的新词，减少未登录词，对改善搜索引擎的用户体验有重要意义。

新词发现的一种常用算法，是 matrix67 大神 2012 年提出的《互联网时代的社会语言学：基于SNS的文本数据挖掘》 https://www.matrix67.com/blog/archives/5044

其主要思路，是统计语料中出现的所有 ngram 子字符串的凝固度，自由度，信息熵。

算法中需要统计所有 ngram 子字符串的左熵右熵，实现该算法时，一般以子字符串为 key，用哈希表来存。

但随着语料库变大时，内存消耗变大，

比如之前的 python 版本实现，对 200MB 的语料，就需要约 30G 内存来存哈希表，

导致单机内存不足无法运行，而且对这样规模的语料库，算法需要跑一两天才能出结果。

这里我应用一些工程实现方面的技巧，把用哈希表统计左熵右熵的计算，拆分成多个子哈希表，分批计算，并利用多核并行，大幅度优化了算法的性能。

最终实现了 GB 大小语料上的新词发现，并把运行时间缩减到了 30 分钟左右。

https://github.com/hankcs/HanLP/wiki/%E6%96%B0%E8%AF%8D%E8%AF%86%E5%88%AB

借助 ext4 文件系统的打洞功能实现消息队列

Sat, 10 Aug 2019 00:00:00 +0000

借助 ext4 文件系统的打洞功能，可以实现一个消息队列 https://gist.github.com/CAFxX/571a1558db9a7b393579

fallocate(fd, FALLOC_FL_PUNCH_HOLE|FALLOC_FL_KEEP_SIZE, offset, length);

Punching holes in files

https://lwn.net/Articles/415889/

怎样对大文件的中间部分进行增删？

首先，如果复制/写文件的后半段的话，肯定是可以实现的，但是这样不“高效”。所以这里的需求是 “怎样在大文件中间 insert 或者 delete 一段数据而不用读写文件的后半部分”。

由于 unix 的历史，并没有直接提供这种 syscall 。

如果用 3.15 之后的 linux kernel ，在 ext4 (only for extent-based files) 和 XFS 文件系统上， http://man7.org/linux/man-pages/man1/fallocate.1.html http://man7.org/linux/man-pages/man2/fallocate.2.html

fallocate 这个 syscall 新增了 FALLOC_FL_COLLAPSE_RANGE (delete 一段) 和 FALLOC_FL_INSERT_RANGE （insert 一段）这两个选项，可以实现在文件系统 block size 边界对齐的 insert/delete 。

Proxygen http2 代码分析

Wed, 08 Mar 2017 00:00:00 +0000

Proxygen 的整体架构

一个 HTTPSession 对应一个 tcp 连接。

HTTPSession 中包含HTTPCodec ，HTTPCodec用来在 HTTPMessage(Request/Response) 和字节流之间做转换（就是解析/序列化）。

一个 HTTPTransaction 对应一个 HTTP2 的Stream ，也就是一次 Req/Resp Handler 是业务逻辑处理的基类。

其中 HTTP2 部分由几个类构成：

codec/HTTPCodec.h
codec/HTTP2Framer.cpp
codec/HTTP2Codec.cpp , HTTPParallelCodec.cpp
codec/Compress/HeaderCodec.cpp,HPACKCodec.cpp
session/HTTPSession.cpp
session/HTTPTransacion.cpp
session/HTTP2PriorityQueue.cpp

1. HTTPCodec.h
#

定义了 HTTPCodec 这个基类，定义了用来在内部的 HTTP Request/Response 和字节流之间做转换的公共接口，是HTTP1.1/SPDY/HTTP2 的公共基类。具体的HTTP2/HTTP1.1等各种协议的编解码，实现在 HTTP1.1/SPDY/HTTP2 等子类中。

1) HTTPCodec
#

HTTPCodec 是 HTTP1.1/ HTTP2 接口的超集，即HTTP1.1也被当成 HTTP2 实现

i. 首先所有的子类都要支持 StreamID，HTTP1.1 由于有KeepAlive，看成有多个Stream。 ii. onIngress()，传入输入数据，驱动解析。 iii. generateHeader()/ generateBody() /generateChunkHeader() /generateGoaway()/ generatePingRequest()/ generatePriority() 等，是 http1.1/http2 的超集。HTTP1xCodec.cpp 是没有实现HTTP2 的这些Frame 的generateXXX函数。HTTP1.1

2) PriorityQueue，优先级队列。
#

Session/HTTP2PriorityQueue.cpp 实现了这个接口类

3) HTTPCodec::Callback 类
#

解析的过程中，需要通知 HTTPCodec 的使用者做一些操作，因此有个接口类 HTTPCodec::Callback，HTTPCodec 的使用者实现 Callback 的子类，传给 HTTPCodec 的子类，HTTPCodec 的子类在解析过程中解析出来的各种消息都回调这个callback。 Callback 的主要方法有:

onMessageBegin()
onHeadersComplete() // HeaderList 接收完
onBody() // Body 开始
onMessageComplete() //Message 整个接收完
onWindowUpdate() // 收到 WindowUpdate Frame
onPriority()， //收到 Priority Frame等

顾名思义，处理HTTPMessage 开始事件，收到各种 HTTP2 Frame 等等。

2. HTTP2Framer.cpp
#

10种Frame 的解析/序列化工具函数，parseXXXFrame, writeXXXFrame，最底层。供HTTP2Codec 使用。

3. HTTP2Codec
#

Framing Layer，即处理 HTTPMesage , HTTP2 Frame 和输入/输出字节流之间的解析/序列化。实现了HTTPParallelCodec(HTTP2和SPDY的公共基类，HTTPCodec 的子类)，HeaderCodec两个接口类

1) 输入字节流的解析的时候，做:
#

i. HEADERS Frame，
#

做各种 Header 的变换处理。

ii. PRIORITY
#

4. compress/HeaderCodec.cpp
#

HeaderCodec 是 Header List 的编解码器。HeaderCodec解码的结果通过 HeaderCodec::StreamingCallback接口类通知给使用者（即HTTP2Codec）。HeaderCodec::StreamingCallback主要有个 onHeader(name, value) 接口(HTTP2Codec实现了)。

5. compress/HPACKCodec.cpp
#

HPACK保存 int –> string 的映射，通过发送 int，代替 string 来压缩。

HPACK编码，主要需要实现动态表，静态表，Huffman encoding，Header序列化/解析。

HPACKCodec 主要有 encode(vector

)/decode(Buffer) 两个接口。重要成员变量：

 HPACKEncoder encoder_;
 HPACKDecoder decoder_;

实际的动态表/静态表逻辑，是一个HeaderTable，主要数据结构就是vector + ，

HPACKDecoder 里面的动态表对应的是 HPACKContext，先 peek 一个字节，判断是否用了HPACKDecodeBuffer来解码

Integer比特编解码，literal编解码，都实现在 HPACKDecodeBuffer / HPACKEncodeBuffer里面。

Huffman encoding 实际使用的是 256位的trie，不是2位的，为了优化性能。

在 HeaderTable.cpp 中，可以看到，实际的 vector 是当成一个环形队列来用的，实际是把 RFC 中规定的 [ 1 — n ] 的区间，逆向映射到这个环形队列中，即 index 1 是，对应到环形队列的尾，index n 是对应到环形队列的头。这样，按照 RFC，增加 Header 进来的时候，应该是加在 1 前面，并把所有的已有 Header 往后挪1个位置，实现上就可以不用做 “挪动”，而且已有的 name–>index 的映射也不用改。这是一种实现上的小技巧。

并用一个

unordered_map<Header.name , list<index> > 

的形式存储 Header.name 到一组 vector 中的 index 的映射，这是由于有相同 name ，对应多个 value 的情况，而且要支持 “查找 name+value 匹配” 和 ”查找 name 匹配“ 两种查找。

6. session/HTTP2PriorityQueue.cpp
#

每一个 Stream都依赖一个 Stream 或者 Stream 0。一个 Stream A 依赖 Stream B ，那么 A 就是 B 的子节点。形成依赖树。 Stream 0 是树的根节点。

HTTP2PriorityQueue实现了PriorityQueue接口类，实现了 addPriorityNode(StreamID id, StreamID parent) 接口

主要的逻辑实现在 Node这个内部类里面。

PriorityQueue 的数据成员，主要是一个 unorder_map<streamID, Node>

Node内部的数据成员：

Node {
 HTTP2PriorityQueue& queue_; //属于哪个 PriorityQueue
 Node *parent_{nullptr}; 		//树中的父节点
 HTTPCodec::StreamID id_{0}; //
 uint16_t weight_{16}; //权重
 HTTPTransaction *txn_{nullptr}; 

 bool isPermanent_{false};
 bool enqueued_{false}; //enqueued 表示在 有输出数据的队列中

 uint64_t totalEnqueuedWeight_{0}; 
 uint64_t totalChildWeight_{0};

 std::list<std::unique_ptr<Node>> children_; // 子节点
 std::list<std::unique_ptr<Node>>::iterator self_; 

 folly::IntrusiveListHook enqueuedHook_; //一个侵入式链表
 folly::IntrusiveList<Node, &Node::enqueuedHook_> enqueuedChildren_; //

}

有输出数据等待发送 (pending Egress) 的 HTTPTransaction ，会加入

signalPendingEgress() ，通知 HTTP2PriorityQueue 某一个 Stream 产生了输出数据。内部实现是把这 Stream加入

clearPendingEgress()，通知一个 Stream 发完了输出数据。

addOrUpdatePriorityNode()，

nextEgress() ，获取有输出数据等待发送的 HTTPTransaction 的列表，列表的每个元素是 pair< HTTPTransaction * ，double weight > ，按照 weight 从大到小排列，列表中的所有weight 加起来等于1。

7. session/HTTPTransaction.cpp
#

HTTPTransaction 表示一次 Req／Resp，HTTPTransaction 需要和 HTTPSession 交互写入 HTTPMessage 所以提出了Transport 这个概念，这样依赖关系就是单向的，没有 HTTPTransaction – HTTPSession 之间不会产生双向依赖。实际处理业务的代码，定义成一个个 Handler，需要与Handler 交互，

1) HTTPTransaction::Transport
#

是 HTTPTransaction 的下层为 HTTPTransaction 提供的输出HTTPMessage 服务。(下层具体指的是 HTTPSession)。

Transport 的方法有：sendHeaders()/sendBody()/pauseIngress()/resumeIngress()/ sendPriority() / 等

2) HTTPTransactionHandler
#

是一个个业务Handler 的基类，Handler的方法有:onHeadersComplete()/onBody()/onChunk/onTrailers/onEgressPaused()/ onEgressResumed等，就是解析出 HTTP Message的各个部分，或者流控发现无法再写了时候的通知。

i. HTTPTransaction::Handler 有好几种,业务Handler 比如直接生成 ErrorPage 的 HTTPDirectResponseHandler就是生成 404 页面的 Handler，在其内部，实现 onHeadersComplete 方法，在这个方法内生成回包数据，然后调用 HTTPTransaction 的 sendHeaders/sendBody 等方法发回给客户端。

3) HTTPTransactionIngressSM
#

由于 HTTPTransaction 要调用 Handler 的好几种方法，内部要记录当前已经处理到哪一步了，不能允许在任意时机，任意来的数据都触发回调，所以搞了两个状态机，HTTPTransactionIngressSM/ HTTPTransactionEgressSM 来明确地规定回调可以触发的顺序。

4) HTTPTransaction 的重要成员变量：
#

streamId, handler_ , transport_ ,egressState_ , ingressState_, recvWindow_ , sendWindow_, HTTP2PrioprityQueue::Handle queueHande_,

8. session/HTTPSession.cpp
#

HTTPSession 针对 HTTP2/HTTP1.1/SPDY的超集的，HTTPSession是一个 HTTPCodec::Callback（接受解析出来的各种 Frame），是 HTTPTransaction::Callback（供HTTPTransaction发送输出 HTTP Message）,是 FlowControlFilter::Callback（接受输出状态打开/关闭的通知）。

1) 重要成员变量：
#

{
 folly::IOBufQueue readBuf_,
 folly::IOBufQueue writeBuf_,
 map<StreamID, HTTPTransaction>transactions_,
 HTTP2PriorityQueue queue,
 FlowControlFilter connFlowControl_,
}			
			

2) getNextToSend()
#

是做发送的，可以看到，proxygen 是按相对权重来分派带宽的。txnEgressQueue_.nextEgress() 取出当前可发送的 HTTPTransaction + 相对权重的列表，然后把可发送字节数按照相对权重分给各个HTTPTransaction。

9. 细节
#

1) IOBufQueue
#

多处用到的基础类：IOBufQueue，Zero-Copy，引用计数。一个 Bufffer Chain，设计类似 linux kernel 的sk_buff, BSD 的 mbuf 。

https://github.com/facebook/folly/blob/master/folly/io/IOBuf.h

 * An IOBuf is a pointer to a buffer of data. *
 * IOBuf objects are intended to be used primarily for networking code, and are
 * modelled somewhat after FreeBSD's mbuf data structure, and Linux's sk_buff structure.
 * IOBuf objects facilitate zero-copy network programming, by allowing multiple
 * IOBuf objects to point to the same underlying buffer of data, using a
 * reference count to track when the buffer is no longer needed and can be freed.

2) HTTPHeaders
#

HTTPHeaders 有个性能优化，用了静态完美hash函数，把常用的 83个 Header 各自唯一地hash 成1 字节，HeaderList 的查找使用汇编实现的memchr。

https://github.com/facebook/proxygen/blob/master/proxygen/lib/http/HTTPHeaders.h

* Headers are stored as Name/Value pairs, in the order they are received on
 * the wire. We hash the names of all common HTTP headers (using a static
 * perfect hash function generated using gperf from HTTPCommonHeaders.gperf)
 * into 1-byte hashes (we call them "codes") and only store these. We search
 * them using memchr, which has an x86_64 assembly implementation with
 * complexity O(n/16) ;)
 

TrafficServer http2 代码分析

Wed, 08 Mar 2017 00:00:00 +0000

TrafficServer 是Apache基金会的 HTTP/HTTP2 代理服务器。

TrafficServer 的 HTTP2 部分主要的代码在 :

trafficserver/proxy/http2/HTTP2.h, HTTP2.cc
trafficserver/proxy/http2/Http2Stream.h, Http2Stream.cc
trafficserver/proxy/http2/Http2ClientSession.h, Http2ClientSession.cc
trafficserver/proxy/http2/Http2ConnectionState.h, Http2ConnectionState.cc
trafficserver/proxy/http2/ Http2DependencyTree.h, Http2DependencyTree.cc
trafficserver/proxy/http2/HPACK.h, HPACK.cc
trafficserver/proxy/http2/HuffmanCodec.h, HuffmanCodec.cc

1. trafficserver/proxy/http2/HTTP2.h, HTTP2.cc
#

10种Frame 的struct定义，解析/序列化函数，HeaderList转换函数，一些常量定义

2. trafficserver/proxy/http2/Http2ClientSession.h, Http2ClientSession.cc
#

Http2ClientSession 处理 io event 事件，解析 FrameHeader，

调用顺序：

Http2ClientSession::main_event_handler()

--> state_read_connection_preface()

--> state_start_frame_read()

--> state_process_frame_read() 解析出一个完整的Frame

--> do_complete_frame_read()

--> Http2ConnectionState::main_event_handler(HTTP2_SESSION_EVENT_RECV )

3. trafficserver/proxy/http2/Http2ConnectionState.h, Http2ConnectionState.cc
#

Http2ConnectionState，对应一个 HTTP2 连接，代码基本等价于 proxygen 的 HTTPSession，主要的成员变量：

{ 
 双链表<Http2Stream> //略挫，有个find_stream 用的遍历，改map好点。

 Http2ClientSession，

 HpackHandle 2个，

 DependencyTree，

 Http2ConnectionSettingsclient_settings server_settings，连接的几个 Settings 配置项，一个int数组
}

主要的方法：各个 rcv_xxx_frame() 和 send_xxx_frame(0 Http2ConnectionState::main_event_handler(HTTP2_SESSION_EVENT_RECV )里面，解析输入的各种 Frame

rcv_data_frame, // HTTP2_FRAME_TYPE_DATA
rcv_headers_frame, // HTTP2_FRAME_TYPE_HEADERS
rcv_priority_frame, // HTTP2_FRAME_TYPE_PRIORITY
rcv_rst_stream_frame, // HTTP2_FRAME_TYPE_RST_STREAM
rcv_settings_frame, // HTTP2_FRAME_TYPE_SETTINGS
rcv_push_promise_frame, // HTTP2_FRAME_TYPE_PUSH_PROMISE
rcv_ping_frame, // HTTP2_FRAME_TYPE_PING
rcv_goaway_frame, // HTTP2_FRAME_TYPE_GOAWAY
rcv_window_update_frame, // HTTP2_FRAME_TYPE_WINDOW_UPDATE
rcv_continuation_frame, // HTTP2_FRAME_TYPE_CONTINUATION

还有发送各类 frame 的接口，send_data_frames()/send_headers_frame() / send_push_promise_frame() / send_rst_stream_frame() 等。

具体地：

rcv_data_frame :
#

find_stream,然后检查stream的state是不是OPEN/HALF_CLOSE_LOCAL，去除 padding，处理END_STREAM flag，检查本端流量控制 window_size ，保存buffer，更新本地的window，发回 Connection 和 Stream Level 的WindowUpdate Frame。

rcv_headers_frame：
#

find_stream/create_stream，处理padding，处理PRIORITY flag添加到 PriorityTree 里面，如果 Header Block 结束了（即有END_HEADERS FLAG），那就http2_decode_header_blocks() 做HPACK 解压缩，调用 Http2Stream 处理解析出的HeaderList

rcv_priority_frame:
#

find_stream，reprioritize，重新调整树。

rcv_rst_stream_frame
#

rcv_settings_frame:
#

parse检查收到的各个配置项，更新到client_settings中，并发送SETTINGS_ACK

rcv_push_promise_frame 等
#

包括 rcv_ping_frame

rcv_goaway_frame:

rcv_window_update_frame

比较简单，略。

rcv_continuation_frame
#

类似 rcv_headers_frame

send_data_frames_depends_on_priority
#

取了 DependencyTree的top()，

send_data_frames 等
#

send_a_data_frame

send_headers_frame

send_push_promise_frame

send_rst_stream_frame

send_settings_frame

send_ping_frame

send_goaway_frame

send_window_update_frame

比较简单，就是检查字段合法性，序列化，然后发送。

4. trafficserver/proxy/http2/Http2Stream.h, Http2Stream.cc
#

对应实现HTTP2 的Stream，重要的成员变量有：

Http2StreamState _state;//实现IDLE，OPEN，RESERVED，HALF_CLOSE等的切换。

DependencyTree::Node *priority_node;// Priority Tree中的节点指针。

5. trafficserver/proxy/http2/Http2DependencyTree.h, Http2DependencyTree.cc
#

Http2DependencyTree::Node 表示一个Stream，成员变量有：

{
 bool actived; //是否有输出数据
 bool queued; //是否在 actived 队列中
 uint32_t id;
 uint32_t weight;
 uint32_t point; //queue中的节点按照这个 point 做优先级排序
 Node *parent; //父节点
 DLL<Node> children; //子节点的双列表
 
 PriorityQueueEntry<Node *> *entry; // 
 PriorityQueue<Node *> *queue; //有输出数据的所有子节点的队列，按point 优先级降序排列

 Http2Stream *t;
}

Http2DependencyTree 中有个 Node * root 指向树的根节点。

Http2DependencyTree的主要方法有：

Node *find(uint32_t id);
DFS 递归遍历树，查找一个Stream。
Node *add(uint32_t parent_id, uint32_t id, uint32_t weight, bool exclusive, T t); 就是插入 parent 的 children 链表中，兼做 exclusive 处理。
void remove(Node *node); 从parent 的 queue 中移除自己，把自己的 queue 全转给 parent，把自己的 children 全转给 parent
void reprioritize(uint32_t new_parent_id, uint32_t id, bool exclusive); 重排优先级，就是移动节点
Node *top(); 返回整个树中，point 最高的叶子节点。递归实现。
void activate(Node *node); 往上遍历，如果当前节点没有在 parent 的 queue中，加入
void deactivate(Node *node, uint32_t sent); 从parent 的queue中去除自己。
void update(Node *node, uint32_t sent);

这里使用 Weighted Fair Queue (WFQ) Scheduling 来调度 Stream 之间的优先级。

Http2ConnectionState::send_data_frames_depends_on_priority() 中，是直接取了树的 top() 节点，

6. trafficserver/proxy/http2/HPACK.h, HPACK.cc
#

实现 HPACK 压缩/解压缩

7. trafficserver/proxy/http2/HuffmanCodec.h, HuffmanCodec.cc
#

实现静态的 Huffman 表，接口简单，只有4个函数，，

是实现成二叉树，相比proxygen估计效率会低一些。

现代密码学实践指南[2015年]

Fri, 05 Jun 2015 00:00:00 +0000

本文介绍目前现代密码学的最先进技术，前半部分主要翻译自《Cryptographic Right Answers》，附上收集的资料，和byron个人的理解。

密码学理论艰深，概念繁多，本人知识水平有限，错误难免，如果您发现错误，请务必指出，非常感谢!

下文分类介绍在各种适用场景下，你应该使用的现代密码学算法
#

1. 加密数据 :
#

按照优先级，应该选择:

(1) 首选 NaCl库，或者libsodium库，使用里面的crypto_secretbox()/crypto_secretbox_open() 函数 (2) Chacha20-Poly1305 算法 (3) AES-GCM 算法

适用场景:当你需要避免把明文数据在网络上传输的时候。

以上3种算法，都是AEAD类的算法，AEAD是2015年最好的选择。其中的(2)和(3)在结构上类似：一个流加密模式的算法，配合一个多项式结构的MAC。 (2)是一个流加密算法，配合一个为通用cpu优化的MAC算法，对密码学库的实现者来说，Poly1305也比GCM更容易安全地实现。 AES-GCM是工业标准(TLS目前主要用的就是AES-GCM)，现代CPU通常都有专门为AES-GCM设计的硬件指令，但是在没有硬件指令支持的CPU上(比如32位的arm)，(3)性能低于(2)。

此外，应该

避免AES-CBC(说来话长，后文有解释)
避免AES-CTR
避免64bit块大小的块加密算法–(说的就是你–BlowFish)
避免OFB模式
不要使用RC4，RC4已经被攻破

2. 对称密钥长度 :
#

选择使用256bit长度的密钥

适用场景：只要你在使用密码学，你就应该注意对称密钥长度

请记住：不要把对称加密（如AES）的key长度，和非对称加密(如RSA)的key长度搞混淆了，对称加密的key通常比非对称加密的key短多了。

下表对比了相同安全程度时，不同算法的密钥长度，单位:bit

Symmetric	ECC	DH/DSA/RSA
80	163	1024
112	233	2048
128	283	3072
192	409	7680
256	571	15360

此外，应该

避免使用巨大key的算法(使用远大于256的key，只能说明使用者没有安全概念)
避免把多个加密算法串联叠加起来使用，这并没有什么卵用
避免128bit以下的key长度(比如，哥们求你别再提DES这种56bit密钥的古董了)

3. 对称签名:
#

应该选择 HMAC 类的算法

适用场景：安全加固一个API，如各种开放API的调用方认证

如果对一个API，你需要做认证(authenticating)，但是不需要做加密(encrypting)，记得千万不要自己发明算法，你自己发明的MAC算法基本都有安全漏洞，如果不信，请Google一下 “长度扩展攻击” 长度扩展攻击 Flickr的漏洞案例

同时，必须要注意的是，要使用一个常数时间字符串对比算法（这个地方和码农的常识完全相反，请务必留意）

此外，应该

避免自行设计的“带密码的hash”结构，你的设计基本都是有安全漏洞的
避免HMAC-MD5，避免HMAC-SHA1，使用HMAC-SHA256, HMAC-SHA512等
避免复杂的多项式MAC
避免加密hash值的结构
避免CRC

4. Hashing/HMAC 算法
#

应该选择SHA2类的算法:: SHA-256, SHA-384, SHA-512, SHA-512/256

优先使用 SHA-512/256，SHA-512/256这个算法把 SHA-512 的512bit输出截短到256bit，避开了length extension 攻击。同时，目前SHA-2是很安全可靠的，你不需要升级到SHA-3.

此外，应该

避免SHA-1
避免MD5
避免MD6

5. 随机ID
#

应该使用256 bit的随机值

一定要使用 /dev/urandom，请认准这个

此外，应该

避免用户空间的随机数生成器如:havaged,prngs,egd,等
避免/dev/random

6. 密码处理
#

按照优先级顺序,选择：

scrypt
bcrypt
如果以上2个都没有，那就用PBKDF2

此外，应该

避免直接SHA-2
避免直接SHA-1
避免直接MD5

7. 非对称加密
#

应该使用NaCl库

适用场景：当你需要加密消息，发给陌生人，并且对方异步接收消息，做离线解密时。这是一个很窄的应用案例，这种用法有个名字叫电子信封(digital envelope)，典型比如gpg加密文件后发送。

这条是几条之中最难做正确的，不要使用底层的密码学库，比如OpenSSL或者BouncyCastle。

你应该停止使用RSA，并且切换到椭圆曲线类体制，原因是：

对RSA的攻击能力的进步 — 定义在传统质数域上的乘法运算(应用包括DH,DSA,ElGamal等)，要比椭圆曲线域上的乘法运算快得多。这是由于质数域上数域筛法（number field sieve,NFS）的进展，而在椭圆曲线域上，没有NFS这类算法。
RSA (和DH) 或迫使你考虑“向后兼容性”，而椭圆曲线体制没有这种兼容性包袱。TLS最近的几个安全漏洞，部分愿意也是由于这种向后兼容性，导致已经被破解的陈旧算法存在
RSA在一般场景中，都是直接用公钥做非对称加密，这种用法丧失了前向安全性(Perfect Forward Secrecy)。而椭圆曲线就不提倡，也很难这样使用，这样你就不会害死自己了。
在椭圆曲线体制下，保证正确性和安全性的重任，主要由密码学家承担，密码学家会提供一组曲线参数，在某一性能水平下，针对安全性和性能做优化。这样程序员不容易误用而害死自己。在RSA体制下，正好相反，程序员必须提供参数来保证正确性和安全性，就算是RSA-OAEP这种很好的设计，程序员也必须知道怎么提供参数，这样程序员很容易搞错。

如果你必须使用RSA，一定要使用RSA-OAEP with SHA256，指数使用 65537

避免 RSA-PKCS1v15
避免 ElGamal
避免 RSA

8. 非对称签名
#

应该使用NaCl，Ed25519，或者RFC6979

应用场景：如果你在设计一种新的比特币，或者一个给Ruby Gems或者Vagrant imges文件签名的系统，或者数字版权保护系统(DRM)，其中一系列的文件需要离线做认证；或者你在设计一个加密消息传输层

上一条的内容在此处全部适用。

在10+年做付费软件安全评估的工作经历中，我只有屈指可数的几次，遇到使用RSA-PSS的用户，RSA-PSS是一个学术界的推荐算法。

过去10年，非对称签名最主要的应用场景是比特币，和前向安全的密钥协商（TLS协议里面的ECDHE）。其中最主要的算法全都是基于椭圆曲线体制的。务必警惕新出现的使用RSA签名的系统，很有可能有问题。

在过去几年中，业界有一种趋势：放弃传统DSA签名，改为难以误用的确定性签名体制，其中的EdDSA(不要和ECDSA搞混了喂！)和RFC6979是最好的例子。这种趋势的主要是受到2010年索尼PlayStation 3的 ECDSA私钥被破解事件的影响，在这个案例中，索尼公司的码农错误地把一个随机数重复使用来做ECDSA签名，形成了漏洞，使得破解者据此直接把私钥算出来了。确定性签名体制在设计中不再依赖随机数生成器，因此彻底避开此类误用。所以你应该优先使用确定性签名体制。

避免RSA-PKCS1v15，避免RSA，避免ECDSA，避免DSA
特别要避免常规的DSA和ECDSA

9. Diffie-Hellman 密钥交换
#

应该使用NaCl，Curve25519，或者DH-2048

适用场景:如果你在设计加密消息传输系统，并且无法使用固定对称密码

这是很棘手的一条，主要考量如下：

如果你能使用NaCl库，那就使用NaCl库。你甚至不需要管NaCl是什么。
如果你能使用一个可信赖的第三方库，那就使用Curve25519，这是一条现代的ECDH曲线，有丰富的开源代码，性能经过高度优化，被彻底地安全分析过。并且Curve25519即将进入TLS 1.3版本标准。
但是绝对不要自己实现Curve25519，也绝对不要自己移植Curve25519的C代码
如果你不能使用第三方ECDH库，但是可以使用DH库，那就使用DH-2048，使用1个标准的2048 bit的群。
但是不要使用传统的DH，如果你需要协商DH参数，或者和其他实现互操作
如果你一定要做握手协商，或者和旧软件互操作，那么考虑使用NIST P-256, NIST P-256 有广泛的软件支持。
写死在代码里的DH-2048参数，比NIST P-256更安全。NIST P-256比协商出来的DH更安全。
但是，由于NIST P-256的实现有一些陷阱，所以一定要谨慎选择可信赖的，广泛使用使的第三方库
P-256 可能是NIST曲线中最安全的，不要使用P-224。

DH（密钥协商）算法确实很难用，但是它很重要。

避免，传统常规的 DH, SRP, J-PAKE 握手和协商
避开任何只使用了块加密算法和srand(time())的密钥协商模式（肯定有漏洞）

10. 网站安全
#

应该使用OpenSSL，或者Google的BoringSSL，或者直接使用 AWS的 ELB

此处网站安全，指的是让网站支持HTTPS协议。如果你不能把这个任务交给Amazon的云服务去做，把难题留给Amazon去解决，那么OpenSSL目前仍然是正确选择。

避免不常见的TLS库，例如polarssl，GnuTLS，MatrixSSL等

11. 客户端-服务器结构的应用程序的安全：
#

应该使用TLS

适用场景：如果你以为自己理解了前面关于公钥加密的介绍。。。

通常，在你设计了自己的RSA协议之后的1至18个月，你肯定会发现，你犯了某个错误，使你的协议没有任何安全性。比如Salt Stack，Salt Stack的协议使用了 e=1 的RSA 公钥。。。

听起来，TLS有下面这些黑历史：

The Logjam DH negotiation attack
The FREAK export cipher attack
The POODLE CBC oracle attack
The RC4 fiasco
The CRIME compression attack
The Lucky13 CBC padding oracle timing attack
The BEAST CBC chained IV attack
Heartbleed
Renegotiation
Triple Handshakes
Compromised CAs

但是，你仍然应该使用TLS做传输协议，因为：

这些漏洞中的大部分，仅仅是针对浏览器的，因为他们依赖受害者执行攻击者控制的JavaScript脚本，这些JavaScript脚本生成重复的明文，或特定的明文。
这些漏洞中的大部分，其影响都可以被减轻，只需要你在代码和配置里面写死 TLS v1.2, ECDHE，和 AES-GCM就行。这听起来很棘手，但是这远远没有你自己设计使用ECDHE和AES-GCM的传输协议棘手。
在一个自定义的传输协议的场景中，你并不需要依赖CA，你可以用一个自签名证书，嵌入到你的客户端里面。
不要自己设计加密传输协议，这是极其困难而易错的工程难题
使用TLS，但是不要使用默认配置

12. 在线备份
#

应该使用Tarsnap

#名词解释

本文的内容比较新，相关中文资料极少，因此文中的名词对读者可能有点陌生，故byron这里介绍一下文中提到的一些名词：

1. NaCl库:
#

http://nacl.cr.yp.to/ 是密码学学术权威 Daniel J. Bernstein教授设计的一个密码学算法库，2008年发开始公布。NaCl的特点是：api简洁而易用，高性能，高安全性，主要用于网络通信，加密，解密，签名等，NaCl提供了构建高层密码学工具的核心功能。

2. libsodium库:
#

https://download.libsodium.org/doc/ libsodium是对NaCl库的一个分支，进一步改进接口易用性，和可移植性。

3. AEAD:
#

https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html AEAD的概念: 在通常的密码学应用中，Confidentiality (保密) 用加密实现，Message authentication (消息认证) 用MAC实现。这两种算法的配合方式，引发了很多安全漏洞，过去曾经有3种方法：1. Encrypt-and-MAC 2.MAC-then-Encrypt 3.Encrypt-then-MAC ，后来发现，1和2都是有安全问题的，所以，2008年起，逐渐提出了“用一个算法在内部同时实现cipher+MAC”的idea，称为AEAD(Authenticated encryption with additional data)。在AEAD这种概念里，cipher+MAC 被一个AEAD算法替换。 http://en.wikipedia.org/wiki/Authenticated_encryption

4. ChaCha20-poly1305
#

ChaCha20-poly1305是一种AEAD，提出者是Daniel J. Bernstein教授，针对移动互联网优化，目前Google对移动客户端的所有流量都使用ChaCha20-Poly1305

5. AES-GCM
#

AES-GCM是一种AEAD，是目前TLS的主力算法，互联网上https流量的大部分依赖使用AES-GCM。

6. AES-GCM和ChaCha20-Poly1305的性能对比测试结果:
#

Chip	AES-128-GCM speed	ChaCha20-Poly1305 speed
OMAP 4460	24.1 MB/s	75.3 MB/s
Snapdragon S4 Pro	41.5 MB/s	130.9 MB/s
Sandy Bridge Xeon (AESNI)	900 MB/s	500 MB/s

7. AES-CBC
#

关于AES-CBC，在AES-GCM流行之前，TLS主要依赖AES-CBC，而由于历史原因，TLS在设计之初固定选择了MAC-then-Encrypt结构，AES-CBC和MAC-then-encrypt结合，为选择密文攻击(CCA)创造了便利条件，TLS历史上有多个漏洞都和CBC模式有关：

The POODLE CBC oracle attack:参考: 1.POODLE的一个分析 2.openssl的分析 3.乌云的文章
The CRIME compression attack:
The Lucky13 CBC padding oracle timing attack:
The BEAST CBC chained IV attack:

8. SHA2
#

http://en.wikipedia.org/wiki/SHA-2

9. Curve25519
#

http://cr.yp.to/ecdh.html Curve25519 是目前最高水平的 Diffie-Hellman函数，适用于广泛的场景，由Daniel J. Bernstein教授设计。由于NIST P-256的设计过程不透明，有来历不明的参数，被广泛怀疑有后门，所以设计了Curve25519，Curve25519的设计过程完全公开，没有任何来历不明的参数。部署情况：http://ianix.com/pub/curve25519-deployment.html

10. Ed25519
#

http://ed25519.cr.yp.to/ Ed25519是一个数字签名算法，

签名和验证的性能都极高，一个4核2.4GHz 的 Westmere cpu，每秒可以验证 71000 个签名
安全性极高，等价于RSA约3000-bit
签名过程不依赖随机数生成器，不依赖hash函数的防碰撞性，没有时间通道攻击的问题
并且签名很小，只有64字节，公钥也很小，只有32字节。部署情况：http://ianix.com/pub/ed25519-deployment.html

11. 前向安全性
#

前向安全性( Perfect Forward Secrecy ) http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html 前向安全性指的是，如果攻击者抓取并保存流量，那么将来私钥泄露后，攻击者也无法利用泄露的私钥解密这些流量。

12. Diffie-Hellman 密钥交换
#

http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange 在任何一本密码学教材里面都会重点介绍的

13. constant time compare
#

针对Timing attack，http://en.wikipedia.org/wiki/Timing_attack （这种攻击真是脑洞大开！）当一个算法的运行时间和输入数据有关的时候，可以根据运行时间这一信息，破解出密钥等。典型的，比如要验证一个对称签名，如果你用了C库里面的memcmp()，那你就会被timing attack方式攻击。因此，涉及到密码学数据的memcmp，必须要用运行时间和输入无关的函数，比如OpenSSL库里面的CRYPTO_memcmp()

nginx下配置高性能，高安全性的https TLS服务

Fri, 08 May 2015 00:00:00 +0000

下文以nginx为例，介绍如何部署一个高性能，高安全性的https服务器。

并附送一个优化出来的openssl编译脚本，可以编译出一个高性能，高安全性的openssl库，您可以直接复制粘贴使用。

此处直接给出实践指导，后续再写文章解释tls协议的这些原理细节。

nginx下https配置的优化点，主要有:

session ticket
session id cache
ocsp stapling
http KeepAlive
ECDHE等ciphersuite优化
openssl 编译优化

一， nginx https的配置
#

先贴一下nginx配置，如下。

是根据mozilla的权威文档 ,和生成工具(选择 nginx，intermediate ) 生成的配置为基础，加入session ticket等配置的结果

server {
 listen 443 ssl;

 # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
 ssl_certificate /path/to/signed_cert_plus_intermediates;
 ssl_certificate_key /path/to/private_key;
 ssl_session_timeout 1d;
 ssl_session_cache shared:SSL:50m;

 ssl_session_ticket_key /etc/nginx/conf.d/tls_session_ticket.key;
 ssl_session_tickets on;
 
 keepalive_timeout 75s;

 # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
 ssl_dhparam /path/to/dhparam.pem;

 # intermediate configuration. tweak to your needs.
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
 ssl_prefer_server_ciphers on;

 # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
 add_header Strict-Transport-Security max-age=15768000;

 # OCSP Stapling ---
 # fetch OCSP records from URL in ssl_certificate and cache them
 ssl_stapling on;
 ssl_stapling_verify on;

 ## verify chain of trust of OCSP response using Root CA and Intermediate certs
 ssl_trusted_certificate /path/to/signed_cert_plus_intermediates;

 resolver 114.114.114.114;
 
 ....
}

二，其中的几个配置项
#

1. /path/to/signed_cert_plus_intermediates
#

是你的证书链，就是ca签署之后发给你的文件，是一串这样的内容

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

2. /path/to/private_key
#

是你的私钥，一定要保密，最好chown+chmod限制只有http server可以读取！内容大致是：

-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

3. /path/to/dhparam.pem
#

是dhe密钥协商的参数，生成方法：

 openssl dhparam -out dhparam.pem 2048

4. /etc/nginx/conf.d/tls_session_ticket.key
#

是用来加解密session ticket的密码文件，这个文件的安全等级应该和私钥一样，最好chmod+chown限制只有http server能读取。生成方法:

 openssl rand 48 > tls_session_ticket.key

最好定期（比如2天一次）轮换，配置文件里把新的key文件放在最前面，旧的在下面，如下

 ssl_session_ticket_key current.key;
 ssl_session_ticket_key previous.key;

5. ssl_trusted_certificate /path/to/signed_cert_plus_intermediates
#

ssl_trusted_certificate，是用来验证ocsp响应的各个ca证书+中级证书，和信任的ca根证书列表。当用来验证ocsp响应的时候，应该配置为你的ca根证书+和中级ca证书的列表，此处可以简单和ssl_certificate使用同一个证书列表文件。
其中当需要使用tls的客户端认证的时候（大多数https server都用不到客户端认证），需要指定信任的ca根证书列表文件, 这个文件在centos里面是/etc/ssl/certs/ca-bundle.trust.crt 这个文件。

配置完成之后，使用ssllabs的这个在线检查工具https://www.ssllabs.com/ssltest/analyze.html 做检查，里面提出的警告，都需要改正。

三， openssl编译优化
#

主流的https server，都是依赖openssl来提供tls协议，openssl本身代码复杂，概念繁多，最近对这方面做了研究，下面是一个深入分析过后的最优化编译配置，可以编译出一个高性能，高安全性的openssl版本，您可以直接复制粘贴使用。

openssl请使用最新的1.0.2a版本，这个版本有intel针对ecdh p256曲线的优化，编译脚本见本文末尾。

编译好之后，需要让nginx使用我们编译的这个openssl库，在centos下，可以用LD_LIBRARY_PATH的办法：

sudo vim /usr/lib/systemd/system/nginx.service

在其中添加一行Environment，如下：

[Service]
...
Environment=LD_LIBRARY_PATH=/usr/local/bin/openssl-1.0.2a_64_build/lib/
ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf
...

其中的路径，请自行修改。

还需要创建软连接，解决so库版本号的问题，如下

ln -s libcrypto.so.1.0.0 libcrypto.so.10
ln -s libssl.so.1.0.0 libssl.so.10

脚本中包含了一个cloudflare的patch，增加chacha20_poly1305 cipher，使用了这个patch之后，可以使用cloudflare的ciphers配置

https://github.com/byronhe/modern-crypto-toolbox/blob/master/build_openssl.sh

apache的安全增强配置(使用mod_chroot,mod_security)

Tue, 17 Aug 2010 00:00:00 +0000

LAMP环境的一般入侵，大致经过sql注入，上传webshell，本地提权至root，安装rootkit等步骤。

采用如下的配置，mod_chroot和单独分区挂载可以让本地提权变得极为困难，而mod-security可以封堵一般的sql注入等应用层攻击。

以下内容是在ubuntu10.04上实践以后总结出来的,直接上命令，就不做过多解释了，水平有限，错误在所难免，欢迎指正。

首先确保apache,php,mysql已经正常工作,出现问题的话，查看 /var/log/apache2, /var/log/syslog, /var/log/mysql/error.log 尤其是apparmor导致的权限错误，不易发现。

一，mod_chroot 的安装与配置
#

1.mod_chroot的安装，配置

目标是chroot到/var/www。

(1) 安装:

sudo service apache2 stop
sudo apt-get libapache2-mod-chroot
sudo vi /etc/apache2/mod-available/mod_chroot.conf

内容为

<IfModulemod_chroot.c>
  LoadFile /lib/libgcc_s.so.1
  ChrootDir /var/www
</IfModule>

sudo a2enmodmod_chroot

/etc/apache2/site-enabled/000-default 中 DocumentRoot 改为 /

sudo ln -s /var/www/var/run/apache2.pid /var/run/apache2.pid

并把

ln -s /var/www/var/run/apache2.pid /var/run/apache2.pid

加到/etc/rc.local中

sudo mkdir /var/www/tmp #放session
sudo chmod 1777tmp
sudo mkdir -p /var/www/var/run/mysqld
sudo ln -s / /var/www/var/www

安装好apache,静态页面和php正常后，弄mysql

sudo service mysql stop.
改/etc/apparmor.d/usr.sbin.mysqld，把"/var/run/mysqld.sock w,“那一行复制并改为 “/var/www/var/run/mysqld.sock w,”
改/etc/mysql/my.cnf 在[client],[mysqld_safe],[mysqld]每一节里socket路径改为 “socket = /var/www/var/run/mysqld/mysqld.sock”
sudo servicemysql start.

一些其他问题

date()不正常，解决办法：

sudo mkdir -p /var/www/usr/share /var/www/etc
sudo cp -rp /usr/share/zoneinfo /var/www/usr/share/
sudo cp /etc/localtime/var/www/etc/

DNS可能出问题(没试过)

sudo cp /etc/resolv.conf/var/www/etc/resolv.conf

找不到错误页面

sudo cp -rp /usr/share/apache2//var/www/usr/share/

二，mod_security 的安装与配置
#

2.mod_security的安装，配置

安装

sudo aptitude install libapache2-mod-security2
sudo cp/usr/share/doc/mod-security-common/examples/rules/modsecurity_crs_10_config.conf  /etc/apache2/mods-enabled/mod-security.conf
sudo a2enmod mod-security
sudo apache2ctl stop

修改 /etc/apache2/mods-available/mod-security.conf 中的 debug_log 和 audit_log 路径到合适的位置，并添加如下两行

Include/usr/share/doc/mod-security-common/examples/rules/modsecurity_crs_10_global_config.conf
Include/usr/share/doc/mod-security-common/examples/rules/base_rules/*.conf

sudo apache2ctl start

#/usr/share/doc/mod-security-common/examples/rules/目录下还有一些规则可用

参照gentoo的ebuild中的如下内容（http://gentoo-portage.com/www-apache/mod_security/ChangeLog）

if ! use vanilla; then 
 mv "${D}"${APACHE_MODULES_CONFDIR}/mod_security/modsecurity_*{41_phpids,50_outbound}*/
 "${D}"${APACHE_MODULES_CONFDIR}/mod_security/optional_rules || die
fi

modsecurity_*{41_phpids,50_outbound}*的这几个规则还是不要用比较好。

另外，http://www.gotroot.com/tiki-index.php?page=mod_security+rules 提供一些规则

三，其他加固措施
#

3.另外，可以把/var/www/放在一个单独的分区上，用noexec,nosuid,nodev参数挂载,打开mysql的apparmor,可以极大增强安全性。

参考资料
#

参考资料： /usr/share/doc/mod-chroot-common/

http://core.segfault.pl/~hobbit/mod_chroot/index.html

http://server.it168.com/a2010/0714/1077/000001077357.shtml

http://www.howtoforge.com/chrooting-apache2-mod-chroot-debian-etch

/usr/share/doc/mod-security-common

补充说明
#

后期补充一些：

chroot的关键是确保/var/www/ ,/var/www/var/www都存在，并且/var/www/var/www 是指向/的符号连接

对apache chroot的过程，我的理解（如有不对，欢迎指正）是

先初始化其他模块
chroot到/var/www
改变当前目录到/var/www(此时实际上是改变到/var/www/var/www目录下)
当http请求到来时，比如http://127.0.0.1/index.php,根据vhost的配置（如果documentroot是/，网页实际放在/var/www/下的话），apache寻找/index.php(实际上是/var/www/index.php)

另外，还有个诊断方法是查看/proc//root和/proc//cwd，一个是apache的root路径，一个是apache的当前目录（是apache的pid ），再看看apache的访问日志

Server on Tech Explorer

用 process_vm_readv() 实现多进程内存队列

一，问题背景 #

二，代码 #

构造最短程序打印自身的 MD5

一，介绍 #

二，用过的一些思路和资源 #

三，没有成功的一些思路 #

三. 代码 #

基于 ElasticSearch 开发垂直搜索系统

一，背景介绍 #

二，架构方案 #

1. 转发代理 proxy #

2. 队列 #

3. 其他工具 #

三，搜索应用开发优化指南 #

1. query DSL 语法 #

2. 分词 #

3.关系型搜索 #

4. 粗排相关性打分 #

4.1. BM25 例解 #

4.2. BM25 shard 调整 #

4.3. BM25 similarity 参数调整 #

四，性能优化 #

1. page cache 内存优化 #

2. int 字段查询优化 #

3. 副本数 replicas num #

4. 多 SSD #

5. 内存配置 #

6. refresh_interval #

pdqsort-qsort

用 abstract unix socket 实现进程单实例运行

一，问题背景 #

二，abstract namespace unix socket #

三，代码 #

Python 自动翻译成 C++ ，彻底保证离线在线特征一致

一，问题背景 #

1.常见的特征工程逻辑 #

二，业务痛点 #

1. 业界方案 #

2. 自动翻译方案 #

(1) .已有方案的缺点 #

(2). 翻译器 #

三，pythran 的使用流程 #

(1). 安装 #

(2). 写 Python 代码 #

(3). Python 转成 C++ #

(4). 写 C++ 代码调用 #

(5). 编译运行 #

四，pythran 的功能与特性 #

(1). 介绍 #

(2). 功能 #

(3). 支持的数据类型和函数 #

五，pythran 的基本原理 #

六，相关文章 #

用 DAT 重实现 CppJieba 中文分词算法，降低 99% 内存消耗

一，问题背景 #

二，实现过程 #

二.1 查内存分布 #

二.2 优化方案 #

1. Double Array Trie 代替 cppjieba::Trie #

2. KeywordExtractor #

二.3 其他问题 #

1. 支持热更新，保证词典和DAT一致 #

2. 代码清理 #

3. 不兼容改动 #

GB 规模语料上的高性能新词发现算法

借助 ext4 文件系统的 打洞 功能实现消息队列

Proxygen http2 代码分析

1. HTTPCodec.h #

1) HTTPCodec #

2) PriorityQueue，优先级队列。 #

3) HTTPCodec::Callback 类 #

2. HTTP2Framer.cpp #

3. HTTP2Codec #

1) 输入字节流的解析的时候，做: #

i. HEADERS Frame， #

ii. PRIORITY #

4. compress/HeaderCodec.cpp #

5. compress/HPACKCodec.cpp #

一，问题背景
#

二，代码
#

一，介绍
#

二，用过的一些思路和资源
#

三，没有成功的一些思路
#

三. 代码
#

一，背景介绍
#

二，架构方案
#

1. 转发代理 proxy
#

2. 队列
#

3. 其他工具
#

三，搜索应用开发优化指南
#

1. query DSL 语法
#

2. 分词
#

3.关系型搜索
#

4. 粗排相关性打分
#

4.1. BM25 例解
#

4.2. BM25 shard 调整
#

4.3. BM25 similarity 参数调整
#

四，性能优化
#

1. page cache 内存优化
#

2. int 字段查询优化
#

3. 副本数 replicas num
#

4. 多 SSD
#

5. 内存配置
#

6. refresh_interval
#

一，问题背景
#

二，abstract namespace unix socket
#

三，代码
#

一，问题背景
#

1.常见的特征工程逻辑
#

二，业务痛点
#

1. 业界方案
#

2. 自动翻译方案
#

(1) .已有方案的缺点
#

(2). 翻译器
#

三，pythran 的使用流程
#

(1). 安装
#

(2). 写 Python 代码
#

(3). Python 转成 C++
#

(4). 写 C++ 代码调用
#

(5). 编译运行
#

四，pythran 的功能与特性
#

(1). 介绍
#

(2). 功能
#

(3). 支持的数据类型和函数
#

五，pythran 的基本原理
#

六，相关文章
#

一，问题背景
#

二，实现过程
#

二.1 查内存分布
#

二.2 优化方案
#

1. Double Array Trie 代替 cppjieba::Trie
#

2. KeywordExtractor
#

二.3 其他问题
#

1. 支持热更新，保证词典和DAT一致
#

2. 代码清理
#

3. 不兼容改动
#

借助 ext4 文件系统的打洞功能实现消息队列

1. HTTPCodec.h
#

1) HTTPCodec
#

2) PriorityQueue，优先级队列。
#

3) HTTPCodec::Callback 类
#

2. HTTP2Framer.cpp
#

3. HTTP2Codec
#

1) 输入字节流的解析的时候，做:
#

i. HEADERS Frame，
#

ii. PRIORITY
#

4. compress/HeaderCodec.cpp
#

5. compress/HPACKCodec.cpp
#

1. trafficserver/proxy/http2/HTTP2.h, HTTP2.cc
#

2. trafficserver/proxy/http2/Http2ClientSession.h, Http2ClientSession.cc
#

3. trafficserver/proxy/http2/Http2ConnectionState.h, Http2ConnectionState.cc
#

rcv_data_frame :
#

rcv_headers_frame：
#

rcv_priority_frame:
#

rcv_rst_stream_frame
#

rcv_settings_frame:
#

rcv_push_promise_frame 等
#

rcv_continuation_frame
#