NanoLog起步笔记-1

背景与上下文

因为工作中用到了NanoLog。有必要研究一下。
前段时间研究了许多内容，以为写了比较详实的笔记，今天找了找，不仅笔记没找到，本来做那的测试工程，也被删除得一干二净。
痛定思痛，记录一下。

写在前面

学习一种新的技术，最好的办法是先不要看，先要思考自己的需求，如果自己来实现，应当如何做。最好写在纸上。
然后再找现成的轮子。这时，不要被这些轮子影响。

Nanolog与一般的实时log的异同

现代log的一般特性

一般的实时log，都是由几个元素构成：
1。 分为client和server。 这样做的目的，是为了做到客户端导步工作，数据放下就扭头就走。不需要客户端自己操作耗时的circle锁和IO。
server则，独占一个core，完成后半段的工作。从buffer取出数据，存入到硬盘中。
这里对于sever端，已有许多选择，例如，不写入磁盘，而是维护一个固定大的内存区块。
甚至，将这个内存建在非分页内存上，以便于程序crash后，甚至OS重启后，数据仍然能够获得。
２。 分为多个client共用一个circlebuffer，还是每client用一个自己私有buffer.
各有利弊。
如果共用一个cirlce buffer，那么，内存总占用量，不因client增加而增加。这种情况，可以将client与线程，甚至是线程更小的粒度绑定。
但这种缺点是极为明显的，随clent的增加，等待circle buffer写锁的时间，越来越长。不得不将部分log丢弃。
３。 对，任何一个log你都必须设计丢弃的机制！这点极为重要！因为，任何一个主动对象都是系统的一个成员，系统第一要务不是完成产品需求和用户的需求，而是自己的生存！系统一定要保证不能被日志累跨。
４。 现代的log，一般都是将client绑在core上，每个core利用目前现代CPU支持的原子操作，忙等待完成写入，而且写入的是自己的私有的buffer，私有的buffer为什么还要加原子锁的原因是，因为OS，可能将当前线程，调往另一个核执行。但，如果采用了亲和性和核隔离，那么，原子锁也不需要。
５。 全面二进制化。消除任何对字符串操作的消耗。

Nanolog的选择

１。 Nanolo的server端，是独立线程，采用了异步io，所以，看起来是两个线程。这个设计，并一定是很理想，事实上，并不理想。如果你想实现全memory log，则需要自己处理一下。
而且异步io，并不是可控的，是OS自动完成的。
２。 client，似乎是以每thread为单位（实际是进程），而不是以core为最小粒度。比如perf，lttng等，它们是以核为单位。
以线程为单位有好处，但缺点是占用内存较多。以及，随着线程增加，server轮循每线程私有buffer获取数据的负但也在增加，日志丢失的可能性多了一项：由于sever忙于处理同类的buffer，而可以导致某个线程的log丢失的概率不再可控。
3。二进制化。这也是现代微秒级以下log必须要做的。
nanolog在这方面，做了许多相对超前和创新的工作。
一般而言，只要二进制化，只能是完全自定义的，例如CTF，以前工在flexran上，Intel的MLog，等等。
但Nanolog，在这方面的尝试，是相当值得肯定的，直接将printf二进制化。
这个许多人的文章写了一些，后面我也会详细讲解。
现在我们可以简单说一下google的开发者，在没有C++17之前，是采用事先预处理方式来实现了，在C++17之后，完全采用compiling time来实现该功能。