分类目录归档：C++

转向量化交易

发表评论

量化交易

量化交易是指以先进的数学模型替代人为的主观判断，利用计算机技术从庞大的历史数据中海选能带来超额收益的多种“大概率”事件以制定策略，极大地减少了投资者情绪波动的影响，避免在市场极度狂热或悲观的情况下作出非理性的投资决策。

就职公司

经传多赢投资咨询有限公司

以前我做什么

2014年毕业, 接触客户端的C++开发工作, 当时主要使用的是window下的duilib开发, 在15年的时候转向linux后端开发, 后面岔开一年左右负责PHP后端开发工作, 直到17年继续负责行情后端的研发, 在18年左右, 正式成为了公司行情后端的组长, 随后一直负责行情后端. 期间带领团队重新建立起了一套完整的行情后端服务, 支持高可用, 水平拆分, 垂直拆分等, 除开一些基础库之外, 全部使用自己编写的框架, 将公司的后端技术水平提升到行业前列.

转方向

与其说是转方向, 不如说是开拓一片新的天地, 行情相关的项目, 已经被我玩透了, 在我手下估计很难再玩出花来. 而量化交易是一片新的蓝海, 可以从0到1搭建出一个完整的量化交易项目, 再均衡各种利弊之后, 依然决定跳出以前的项目组, 转向量化交易.

量化交易系统到底在做什么

从20年开始, 公司资管部门的负责人就已经跟我再搭线, 帮忙做量化交易系统。那么到底什么事量化交易系统呢？ 网上有很多种定义, 但是从程序员的角度上看呢, 量化交易 = 策略 + 机器交易, 策略根据行情，持仓等各种因素产生交易信号, 然后程序化的下单。虽然只有两句话, 但是实际里面的行为是非常复杂的, 市面上的量化交易系统, 大多比较复杂, 看他们的PPT都吹得牛逼哄哄的, 也不知道是真的还是假的. 但是每个公司的需求不一样, 做出的量化系统也各有千秋.

继续阅读 →

决战客户端技术

1条回复

　　最近经常有小伙伴问我要做一个客户端, 该怎么弄. 这个问题问得很粗犷, 但是实际上客户端的选型是一个很细的问题. 从大学到现在, 也弄了不少的客户端, 从公司主营炒股专业客户端, 到内部项目使用的OA客户端, 还有大学的时候为了毕业而弄的QT, 各式各样, 这里就给大家讲解一下, 我所了解的几种客户端的选型(这里主要针对windows，也会提及一些跨平台技术).

　　windows下的客户端都是基于win32, 在这基础上, 我们可以细分为, 原生win32, MFC, C#(语言封装), 高级win32-duilib, QT, CEF, electron(nwjs) 大体就这几种了, 其中很多是重合的, 下面我们就每个都讲一讲优劣.
继续阅读 →

线程池的自我修养

1条回复

最近重构行情服务端的框架，其中有一部分就是重写mysql线程池，线程池是一个很独立的东西，今天就拿出来给大家分享, 怎样设计一个线程池, 以及我是怎么做的.

为什么要使用线程池

常见的线程池使用场景分为两种

  1. 大量计算, 充分利用多核

这个很好理解, 当程序需要大量计算, 单核CPU跑到100%, 这个时候可以将计算任务分解, 分多个线程计算, 如果我们有4核, 那这个时候我们可以跑到400%, 理想情况下, 可以节省3倍的时间. 当然这个不是绝对的, 具体情况要具体分析. 总而言之, 是为了让程序充分打满CPU.

  1. 同步阻塞,转异步回调

如果这个是web程序, 异步绝对是提高并发的神器. 在我们的C++服务器中, 也会有大量的阻塞任务, 可能是读取mysql, 可能是读取mongodb, 或者任意需要同步等待完成的事情, 那么在等待的时候, 我们的工作线程是完全没法做别的工作的, 这个时候我们就把等待的过程, 变成一个任务, 让线程池去做, 主线程继续处理别的工作, 等线程池完成之后, 再接管任务, 继续往下面执行.

继续阅读 →

CLion 远程编译调试

发表评论

eclipse cdt 使用rse

尝试和很久使用eclipse cdt的rse实现远程编译, 最后终于放弃了, 个人觉得自己的折腾能力还是很强的, 我花了两天的时间研究, 最后还是失败了, 大家还是不要尝试了.

为什么要使用远程编译

普通的PC机器, 性能太渣, 随随便便编译一下就卡死了, 特别是调试程序的时候, 我们的程序动不动就30多个G的内存, 普通的PC机器根本扛不起来, 公司的高配机器有很好的性能, 放一台在内网做公共的开发机器, 能极大的提高效率.
继续阅读 →

sort 导致进程崩溃

发表评论

转载自沙子泥巴刘的博客

前言

最近被一个在sort自定义排序导致的崩溃问题, 弄得焦头烂额. 后在网上看了这篇文章, 才解决问题, 转载一次.

正文

近期我们开发的一个工具在调用c++ sort函数对数组进行排序时居然会导致进程崩溃，此问题细节我觉得对于类似我这种不常用stl的同学可能不容易觉察，这里简单总结下。

出错代码

因为代码太复杂不好展示，我这里就用下面这个简单的示例来描述。

#include <algorithm>

bool comp(int d1, int d2)
{
    return d1 >= d2;
}

const int N = 50;

int main()
{
    int d[N];
    for(int i = 0; i < N; ++i)
    {
        d[i] = 20;
    }

    std::sort(d, d + N, comp);
    return 0;
}

不知你是否直觉上也会觉得这段代码没什么问题，但是这段代码运行后会core dump。查看core文件可以看到内存里的栈被写坏了，这说明sort调用导致了内存越界访问，在这么少的代码行下，不难判定应该是comp函数实现可能不符合c++标准库的某种规则（C++ STL是基于concept的设计和实现）。
继续阅读 →

流量优化

发表评论

服务器带宽流量

带宽跟流量是个怎么也不能忽略的问题, 如果无法做好流量优化, 服务端写得再好, 客户端依然会卡.

客户端卡顿分析

如果服务器与客户端之间, 平均流量为100k, 客户端的网络情况为200k, 那么平时推送客户端不会卡顿, 可是实际上客户端会生成某些数据,这些数据的生成需要大量的历史数据才能完成, 假设需要2M的历史数据. 那么实际上我们将花费10秒左右的时间才能完成此数据的推送. 这个时候整个客户端会表现为不走数据, 用户就会觉得, 这是什么鬼!!!
继续阅读 →

hiredis 异步

发表评论

hiredis

hiredis是redis官方库, 提供了同步与异步的接口. 对于高性能的服务器, 异步的接口给我们很大的发挥空间.

同步还是异步

使用同步还是异步并没有绝对的定论, 我们可以根据一些性能表现确定使用同步或是异步. redis性能非常好, 以至于在插入或是读取单条数据的时候几乎是感觉不到差异的. 可是一旦同时插入大量数据, 同步延迟非常严重, 读取平均长度30的kv, 大约是10万/秒, 如果我们有千万级别的数据, 整个卡顿会上分钟, 而且带宽会被打满, 所以一般大数据的读取, 我们会采用异步的方法.
继续阅读 →

libevent zmq消息无法响应

发表评论

前言

服务器使用libevent做事件循环, 然后使用zmq做线程间通讯, libevent监听zmq的消息, 一旦zmq有消息过来, 就会回调到固定的函数。使用zmq需要注意的是, 一旦zmq消息回调, 必须读空整个队列的消息. 否则下次就不会回调。

问题症状

我们使用libevent监听了多个zmq, 同时监听了别的事件(退出事件等). 其中有一个zmq消息非常繁忙， 每秒会产生上万到十万不等的数据. 这种时候会发现libevent再也无法响应其他消息。
继续阅读 →

ZMQ 高级请求-应答封包解包

发表评论

我理解的ZMQ

ZMQ不是消息队列, 是一套构建消息队列的组件集合, 它告诉你每个组件有什么特性, 每个组件可以干什么, 至于怎么构建消息队列, 全凭自己决定. 我们可以搭建出同步的, 异步的, 可靠的, 不可靠的, 分布式的, 非分布式的等等. 正是这种灵活的方式, ZMQ才能满足各式各样的需求(借别人一句话:ZMQ就像是一盒积木，只要你有足够的想象力，就可以用它组装出任何造型的网络架构).
继续阅读 →