std::endl将导致程序变慢

最近在写hadoop的streaming任务,在输出的时候用了std::endl,就像下面这样:

os << "content" << std::endl

运行后发现程序跑的比python还慢,令人费解。我入门C++的时候,输出hello world也是这样写的,有什么问题?

于是查了一下std::endl,发现问题挺大。std::endl解释如下:

Inserts a new-line character and flushes the stream.
Its behavior is equivalent to calling os.put('\n') (or os.put(os.widen('\n')) for character types other than char), and then os.flush().

也就是说每次执行到std::endl的时候都会将缓冲区的内容写入到输出的对象中,这样一来速度慢也就不足为奇。

性能测试

#include "timer.h"
#include <fstream>
#include <iostream>

int main() {
    {
        Timer timer;
        fstream fs("./with_endl.txt", std::fstream::out);
        for (int i = 0; i<100000; i++) {
            fs << "test" << std::endl;
        }
        std::cout << "with endl:" << timer.elapsed() << "ms \n";
    }

    {
        Timer timer;
        fstream fs("./without_endl.txt", std::fstream::out);
        for (int i = 0; i<100000; i++) {
            fs << "test" << "\n";
        }
        std::cout << "without endl:" <<timer.elapsed() << "ms \n";
    }

}
with endl:397ms 
without endl:18ms 

不加std::endl性能高出20倍。

C++中zlib的crc32和python zlib.crc32结果不一致的解决方案

背景

python和c++的代码中均有使用crc32分流的操作,需要保证分流得到的结果一致,那么两个crc32的方法得到的结果需要一致才行。然而实际测试中发现python2中zlib.crc32和c++的zlib中crc32得到的结果却不一致。

问题复现

python版crc32

import zlib
print zlib.crc32("helloworld")

结果为 -102031187。

如下:

C++ 版zlib crc32

#include <zlib.h>
#include <iostream>

int main() {
    std::string str = "helloworld";
    std::cout << crc32(0, reinterpret_cast<unsigned const char*>(&str[0]), str.size()) << std::endl;
    return 0;
}

运行结果为:4192936109

python版得出的结果是-102031187,而C++版本得出的结果是4192936109。

(更多…)

股市涨跌的秘密

本文利用神经网络对股市的预测结果作为分析的对象,打开神经网络的黑箱,找到股市中涨跌的秘密。

量价特征

想要预测股市涨跌,就需要了解在股票上涨和下跌的时候,前一天发生了什么。就好像我们想要预测明天天气的时候,总会想尽办法找到过去几十年甚至几百年下雨的前一段时间都有哪些征兆。预测股票也一样,我们需要想尽一切办法找到某只股票过去几年里面价格上涨的前一天都有哪些特征,越全面越好。

找特征不是一件简单的事情,有效的特征可以为我们增加预测的精准度,而无效的特征会对训练造成干扰。首先从最简单的量价特征开始,即今天的股票的价格变化和交易量变化。

为什么是这两个特征?我的理论依据是市场所有的信息最终都会体现在今天的交易价格和交易量上。这两个特征一定是有效的特征。

为了让预测更加准确,我们加上一个五日均价变化,体现股票最近一段时间的价格变化趋势。

为了尽可能减少可能存在的人为操控股市的影响,我选择了沪深300指数作为分析对象,沪深300整体交易量大,波动小,比较适合分析。

构建一个单层一个节点的网络,如下图,这样训练得到的结果得出来的参数我们会有一个直观的印象。


假设R是股票明日的最终涨跌情况,涨为1、跌为0,那么这个网络想要表示的就是价格变化,量变化,五日均价变化分别和未来的涨跌到底是正相关还是负相关。

(更多…)

openssl生成rsa公钥私钥

输入opensslj你如openssl交互界面

OpenSSL>

生成rsa私钥

OpenSSL> genrsa -out private_key 1024
Generating RSA private key, 1024 bit long modulus
………………….++++++
…………++++++
e is 65537 (0x10001)

生成公钥

OpenSSL> rsa -in private_key -pubout -out public_key
writing RSA key

设计模式:装饰器模式介绍和应用

简短描述

当前有一个功能完善的对象,如果我们想要给这个对象添加一个新的职责,那么我们可以用一个新的类去装饰它来实现对原有对象职责的扩展。新的类称为“装饰者”,原有的对象称为“被装饰者”。这种模式被称为装饰器模式。

现实生活中的装饰器模式

装饰器模式在现实生活中的例子简直太多了。比如我开了一个奶茶店,卖的是普通的奶茶。现在我想引入一个叫珍珠奶茶的商品,我要怎么做呢?

我是不是需要升级一下我的制作奶茶的机器,让它支持珍珠奶茶的做法?但这种成本估计比较高,说不定还没原来做奶茶的机器好用呢!实际上我只需要买一个能做“珍珠”的机器就行!把“珍珠”放进奶茶不就成了珍珠奶茶。原有的做奶茶的机器依然可以稳定地制作做奶茶,也避免花成本去学习操作新的机器。

在这个案例中,珍珠就是装饰者,奶茶就是被装饰者。

很容易就写出一个上面所描述的装饰器模式的代码。 首先定义一个饮料接口

interface Drink
{
    public function getPrice();
}

我们现在已经在卖奶茶了,下面是一个奶茶的类。价格已经订好了,10元!

class MilkTea implements Drink
{
    public function getPrice()
    {
        return 10;
    }
}

接着有一个新的品种,叫珍珠奶茶,我只要写一个珍珠的类,然后装饰一下奶茶,这个奶茶就成了珍珠奶茶。

class Boba implements Drink
{
    public function __construct($MilkTea)
    {
        $this->MilkTea = $MilkTea;
    }

    public function getPrice()
    {
        return $this->MilkTea->getPrice() + 5;
    }
}

看看珍珠奶茶是怎么制造出来的

// 先把奶茶做出来
$MilkTea = new MilkTea();
// 用珍珠去装饰这个奶茶,变成了波霸奶茶
$Boba = new Boba($MilkTea);
// 看看现在波霸奶茶的价格
echo $Boba->getPrice();

装饰模式使用起来还是非常容易的。在实际应用中,装饰器模式使用场景也十分广泛。

装饰器应用场景一:参数验证

api中参数验证是必不可少的,我们会选择一些已经很成熟的参数验证器,假如现在有一个非常成熟的参数验证器叫validator,我们现在用的也非常好。

突然有一天,一个需求说接口需要增加一个签名验证,然而现有的验证器不支持该功能,怎么解决呢?

第一反应可能是直接修改这个验证器,让其增加签名验证功能,但这样可不是个很好的解决方案。一个是直接修改会引入风险,一个是如果后续有更多需求,这个稳定的验证器可能会被改的一团糟,还有就是增加一个业务的需求可能让这个验证器变得有点“多事”了…

这个时候装饰器就派上用场了,不修改原有的验证器,用一个新的验证器去装饰原有的验证器就好啦!新的验证器就是为当前业务定制的专有验证器,而原来的验证器也保持了它只该有的功能。

装饰器应用场景二:日志记录

现在有一个使用了很久的日志记录类,代码写的还行,使用也很稳定,但是功能比较单一,仅仅是把日志写入一个文件就完事了。

我突发奇想想让这个日志类能够自动实现根据日期归档,这个时候我就可以写一个装饰器,这个装饰器实现了文件归档的功能,去装饰日志记录类,装饰之后的日志记录类就成为了一个带有文件归档的日志记录类。

设计模式:观察者模式介绍与应用场景

简短描述

在观察者模式中,有一个主题和几个观察者,主题状态改变之后会通知到所有的观察者。

现实中的观察者模式

观察者模式和现实世界很好对应。比如我和我的朋友们购买了今年一年的报纸,每次报社印刷了今天的报纸之后就会往我这里送。在这个系统里面,“报社“是一个主题,“我和我的朋友们”就是一个观察者,当“报社”生产报纸之后,“我和我的朋友们”都能收到这份报纸。

根据上面的描述,我们很容易写出一个观察者模式。首先定义一个报社作为主题,然后定义一些用户作为观察者。不过在此之前,我们先定义主题和观察者的接口,毕竟我们是面向接口编程。

定义一个主题接口

namespace ds\observer\contract;

/**
 * 主题接口
 */

interface Subject
{
    /**
     * 添加一个观察者
     * @param Observer $observer
     */
    public function add(Observer $observer);
    
    /**
     * 移除一个观察者
     * @param  Observer $observer
     * @return boolean
     */
    public function remove(Observer $observer);
    
    /**
     * 通知所有观察者
     * @param  mixed $data
     * @return boolean
     */
    public function notify($data);
}

定义一个观察者接口

namespace ds\observer\contract;

/**
 * 观察者
 */
interface Observer
{
    /**
     * 执行自己的逻辑
     * @param  mixed $data
     * @return boolean
     */
    public function execute($data);
}

定义报社,实现主题接口

namespace ds\observer;

/**
 * 报社主题
 */
class Newspaper implements contract\Subject
{
    protected $Observers;

    /**
     * 添加一个观察者
     * @param Observer $observer
     */
    public function add(contract\Observer $observer)
    {
        $hash = $this->hash($observer);
        $this->Observers[$hash] = $observer;
    }
    
    /**
     * 移除一个观察者
     * @param  Observer $observer
     */
    public function remove(contract\Observer $observer)
    {
        $hash = $this->hash($observer);
        unset($this->Observers[$hash]);
    }
    
    /**
     * 通知所有观察者
     * @param  mixed $data
     * @return boolean
     */
    public function notify($data)
    {
        foreach ($this->Observers as $observer) {
            $observer->execute($data);
        }
    }

    protected function hash($obj)
    {
        return spl_object_hash($obj);
    }
}

定义用户,实现观察者接口

namespace ds\observer;

/**
 * 用户
 */
class User implements contract\Observer
{
    public function __construct($name)
    {
        $this->name = $name;
    }

    /**
     * 执行观察者自身逻辑
     * @param  string $data
     * @return void
     */
    public function execute($data)
    {
        echo $this->name . "收到了" . $data . "\n";
    }

    public function attach(contract\Subject $subject)
    {
        $subject->add($this);
    }
}

执行主流程

到目前位置,我们创建了主题-报社、观察者-用户,他们分别实现了相应的接口,看起来一切准备就绪了。接着这些代码就可以跑起来了。

namespace ds\observer;

require __DIR__ . '/contract/Observer.php';
require __DIR__ . '/contract/Subject.php';
require __DIR__ . '/Newspaper.php';
require __DIR__ . '/User.php';

// 创建一个新的报社
$newspaper = new Newspaper();

// 创建一个新的用户cmhc
$cmhc = new User('cmhc');
// 让这个用户去订阅这个报纸
$cmhc->attach($newspaper);

// 再创建一个用户xiaoming
$xiaoming = new User('xiaoming');
// 让xiaoming也订阅这个报社
$xiaoming->attach($newspaper);

// 报社今天发布了一个观察者模式,通知一下订阅我的人
$newspaper->notify('《设计模式之观察者模式》');

如果执行上面的代码,你会得到如下结果:

cmhc收到了《设计模式之观察者模式》
xiaoming收到了《设计模式之观察者模式》

可能很多人都知道观察者模式,也知道观察者模式要怎么去实现,但是却找不到具体的业务场景去使用它。但实际上观察者模式的应用是十分广泛的。下面就介绍几个经常使用观察者模式的几个场景

支付场景

在支付场景下,用户购买一件商品,当支付成功之后三方会回调自身,在这个时候系统可能会有很多需要执行的逻辑(如:更新订单状态,发送邮件通知,赠送礼品…),这些逻辑之间并没有强耦合,因此天然适合使用观察者模式去实现这些功能,当有更多的操作时,只需要添加新的观察者就能实现,完美实现了对修改关闭,对扩展开放的开闭原则。

UGC场景

在一个UGC场景下,用户发布的内容往往会经过很多流程,大部分是先发往审核系统,当审核通过之后就会出现一系列的业务逻辑,比如更新内容状态,通知给所有的粉丝等等。

解决sqlite中union的子句不能使用order by和limit问题

有一种场景,我们需要在同一张表中找出几个分类的文章,并且按照时间排序,通常我们会这样写(假设表名称是post):

SELECT * FROM post WHERE category_id=1 ORDER BY create_time DESC LIMIT 10

如果有多个分类,我们会考虑将几个语句使用union all连接

SELECT * FROM post WHERE category_id=1 ORDER BY create_time DESC LIMIT 10
UNION ALL
SELECT * FROM post WHERE category_id=2 ORDER BY create_time DESC LIMIT 10

但是这个语句在sqlite是行不通的,sqllite的order和limit不能在union子句执行,这个时候可以使用子查询实现,比如:

SELECT * FROM (SELECT * FROM post WHERE category_id=1 ORDER BY create_time DESC LIMIT 10)
UNION ALL
SELECT * FROM (SELECT * FROM post WHERE category_id=1 ORDER BY create_time DESC LIMIT 10)

布隆过滤器(bloom filter)介绍以及php和redis实现布隆过滤器实现方法

引言

在介绍布隆过滤器之前我们首先引入几个场景。

场景一

在一个高并发的计数系统中,如果一个key没有计数,此时我们应该返回0,但是访问的key不存在,相当于每次访问缓存都不起作用了。那么如何避免频繁访问数量为0的key而导致的缓存被击穿?

有人说, 将这个key的值置为0存入缓存不就行了吗?确实,这是一个好的方案。大部分情况我们都是这样做的,当访问一个不存在的key的时候,设置一个带有过期时间的标志,然后放入缓存。不过这样做的缺点也很明显,浪费内存和无法抵御随机key攻击。

场景二

在一个黑名单系统中,我们需要设置很多黑名单内容。比如一个邮件系统,我们需要设置黑名单用户,当判断垃圾邮件的时候,要怎么去做。比如爬虫系统,我们要记录下来已经访问过的链接避免下次访问重复的链接。

在邮件很少或者用户很少的情况下,我们用普通数据库自带的查询就能完成。在数据量太多的时候,为了保证速度,通常情况下我们会将结果缓存到内存中,数据结构用hash表。这种查找的速度是O(1),但是内存消耗也是惊人的。打个比方,假如我们要存10亿条数据,每条数据平均占据32个字节,那么需要的内存是64G,这已经是一个惊人的大小了。

一种解决思路

能不能有一种思路,查询的速度是O(1),消耗内存特别小呢?前辈门早就想出了一个很好的解决方案。由于上面说的场景判断的结果只有两种状态(是或者不是,存在或者不存在),那么对于所存的数据完全可以用位来表示!数据本身则可以通过一个hash函数计算出一个key,这个key是一个位置,而这个key所对的值就是0或者1(因为只有两种状态),如下图:

(更多…)