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

一,介绍

比赛题目很简单:构造一个程序,在 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 实现,没有动用汇编。

基于 ElasticSearch 开发垂直搜索系统

一,背景介绍

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

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

  1. 全文搜索引擎
  2. NOSQL 数据库
  3. 日志分析数据库 ELK

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

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

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

怎样让 C++ 中 throw exception 产生的 coredump 带上栈

1. 问题

一个 C++ 程序,如果 throw 了 exception ,但是又没有 catch,那么一般会产生 coredump, 问题是,在 gcc 4.x 版本产生的 coredump 文件中,没有 throw 时候的堆栈信息,导致不知道是哪里 throw 的,没法查问题。

原因是 gcc 4.x 的 /libstdc++-v3/src/c++11/thread.cc:92 里面有个 catch(…),所以 stack unwind 了,就没了 throw 时候的 stack 。

1
2
3
4
5
6
7
void * execute_native_thread_routine(){
    try {
     ...   
    }catch(...){
        std::terminate();
    }
}

https://abcdabcd987.com/libstdc++-bug/

一个解决办法是可以升级 GCC 7 ,或者可以用更简单的办法:

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

一,问题背景

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

有几种方法:

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 )

但是这种方法有些弊端:

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

二,abstract namespace unix socket

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

unix socket 有3种:

  1. 基于文件的
  2. socketpair 创建的,匿名的
  3. abstract namespace 的,Linux特有

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

相比 普通的基于文件系统的 unix socket,abstract namespace unix socket :

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

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

一,问题背景

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

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

1.常见的特征工程逻辑

常见的特征工程逻辑有:

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

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

二,业务痛点

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

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

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