很早以前,在学习使用 Python 的 deque
容器时,我实现了一个玩具版的频率限制器。最近需要压测线上服务的性能,又不愿意总是在 QA 那边排队,于是需要自己写一个压测用的客户端。其中一个核心需求就是要实现 QPS 限制。
于是,终究逃不开要在 C++ 中实现一个线程安全的频率限制器。
很早以前,在学习使用 Python 的 deque
容器时,我实现了一个玩具版的频率限制器。最近需要压测线上服务的性能,又不愿意总是在 QA 那边排队,于是需要自己写一个压测用的客户端。其中一个核心需求就是要实现 QPS 限制。
于是,终究逃不开要在 C++ 中实现一个线程安全的频率限制器。
在实际工作一个典型的机器学习任务中,我们在线上和线下都要对特征数据进行处理。线上处理的目的是为了推理预测,线下处理的目的则是为了准备训练数据。显然,因为处理区分线上线下,数据一致性就会成为非常关键的问题。
然而,数据一致性是挺烫手的山芋。因为,如果尝试在线上线下先后两次实现同样的功能,不论如何小心,都有出错的可能。更不用说,如果使用不同语言,那对于数据处理上的些微不同最终都可能破坏数据一致性。
因此,保证数据一致性最好的办法就是用一份代码在两个地方干同样的事情。我们线上服务是用 C++ 编写的,因此我们可以将特征 ETL 抽象成单独的模块,分别链接到线上服务以及离线特征处理程序中。这样,二者对于特征的 ETL 的行为就完全一致了。
剩下的问题就是:离线数据通过 Kafka 落在 Hive 表当中,我们需要在 Hive 处理数据的过程中,嵌入我们自己编写的特征处理程序。
Protobuf(全称 Protocal Buffer,简称 pb)是 Google 开源的序列化/反序列化工具,在工业界相当流行。pb3 相比 pb2 的一个显著变化,就是在 pb3 当中不再区分 required
和 optional
字段。与此同时,在 pb2 中针对 optional
基本类型字段设计的 [default = foobar]
的默认值功能和 has_xxx()
的接口也随之消失。这样引出来一个问题,即:
0
/0.0
/""
/false
」等价;但是特别地,在序列化 - 反序列化之后,如果拿到一个零值,你无法得知这个值是确实为零值,还是说因为没有显示设置而得到的零值。本文在 C++ 场景下来解决这个问题。
虽然站在如今(2020-04-30),CTeX 套装已经应该被扫进历史的垃圾桶。但是,CTeX 套装曾经的贡献不应该被一并扫进垃圾桶。
CTeX 套装是很多人用的第一个 TeX 发行版。其中的 WinEdt 编辑器,也是非常优秀的 TeX 编辑器,很多人更是用顺手了不乐意换。于是,如何方便地切换到 TeX Live 2020,并允许用户在需要的时候切回 CTeX 套装就是个问题了。
本文来解决它。