CRM能解决什么问题
鹏为软件、让管理变得更简单！为您解答。
对于企业来说，客户管理无比重要。每一个企业都有一定数量的客户群，企业只有对客户的需求进行深层次研究，才有可能带来更多的商业机会。在实施客户关系管理过程中，系统会产生大量有用的客户数据，利用智能的分析工具即可发现很多客户的潜在需求，从而实现针对性营销策略。
所以说通过crm可以降低成本，增加收入；提高业务运作效率；可以为客户提供个性化的服务，保留客户，提高客户忠诚度；能筛选出正确的客户群；有助于拓展市场；有利于挖掘客户的潜在需求，实现针对性营销策略。
zeromq解决了什么问题
很早就听说了zeromq 这个项目,当时不太在意.后来同事kasicass 对这个项目做了研究和分享 ,开始重视起这个项目来.1) libevent封装了对网络I/O,信号,定时器等的处理,可以基于它之上做网络层的开发.2) ACE封装了不同平台下的系统调用,也提供好几种网络编程的模型.然而,zeromq不是libevent,也不是ACE,因为它的主要特性是:面向消息进行通信.所以,它提供的是比libevent,ACE处在网络通信中更高一层的组件.使用它,程序员不再需要上面提到的libevent,ACE之类的库需要关心的东西,程序员如果要使用zeromq,只需要做如下的事情:1) 告知所使用的patten,比如request-reply,pub-sub,push-pull等(下面会详细解释这个pattern).2) 告知是用于机器之间,还是进程之间,线程之间的通信.然后,将所需要发送的数据封装到zeromq自带的msg结构体中发送出去,使用者自己关心如何序列化/反序列化这些数据,然后如何处理这些数据就是使用者的事情了.这样看上来,使用者要关注的事情”高”了一层,大部分的精力都可以放在业务逻辑之上了.简而言之,它让使用者的精力放在了通信模式和业务逻辑上,而不是更下面一层的网络层上.下面解释一下zeromq常用的几种网络pattern:1) request-reply就是一般的C/S架构中,client与server之间一问一答的通信模式,比如最经典的echo服务.需要注意的是,client发送一个request,server必须有一个回应.server端作为publish端,而任何连接到服务端的client都会成为subscribe端.也就是说,server端会把当前的所有需要publish出去的消息全部发送到当前连接上去的client上.3) push-pullserver端作为push端,而client端作为pull端.如果有多个client端同时连接到这个server,则服务器会在内部做一个负载均衡,采用平均分配的算法,将所有的消息均衡发布到client端上.看上去,很稀松平常?接下来亮点真的来了.考虑如下一种场景.一个server端做为一组服务器集群最上层的一个proxy,起到负载均衡的作用,将请求按照它下面对应服务器集群依次派发到不同的 client端进行处理.某个时刻可能处理的机器只有2台,而随着负载越来越大,可能需要3台机器了,这个时候如果使用zeromq的push-pull 搭建的proxy端,则可以不用对之前搭建的server,client端进行停机,只需要新启动一个client连接上去,proxy层就会自动根据当前的机器分配平均派发任务了.cool.实际上,这些模式并不是什么新东西,只不过zeromq为使用者做了一个封装,而不是像libevent,ACE等还局限在网络层部分的封装,它关注的是通信层,通信模式等.个人感觉,zeromq部分解决 了erlang所要解决的问题:在多台机器中通信,派发任务等,是分布式通信的利器,但是局限于语言的限制,它没有办法做的跟erlang一样的完善(erlang已经可以算的上一个简易微型的OS了),但是许多的时候,似乎只使用这一部分功能也就足够了.zeromq的代码量,截至到我目前阅读的2.0.10-stable版本,也只有不到2W行代码.提供出去的API也极为简单,但是内部的实现比较”绕”,zeromq是我阅读过的项目中少数的非常需要依赖调试工具跟进代码才能看懂代码流程的项目,同时代码中类的继承层次也比较多,阅读起来并不像它提供的API那样简单直白.后续会对其中的一些难点做一些分析.
谁能解释一下epoll，libevent，zeroMQ的区别
epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般操作系统均有实现。
网上现在关于这两者不同的介绍已经到处都是了。我这里也不能多说出什么东西，只是记录下我看了实现代码之后的一些总结。
两者的使用场景一般是通过一个入口能够同时监控多路I/O。一般使用的接口，
epool就是
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);
select为：
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
通过上述两个函数能够将调用线程阻塞，线程变为可执行条件有两种情况：
无任何事件发生，超时时间已过
在所控制的I/O有事件到来
epoll_wait函数中看不到相关的监控信息，因为是通过epoll_ctl已经加入，而select之间在函数调用中由（fd_set *readfds, fd_set *writefds, fd_set *exceptfds）传入。epoll_wait饭互结果通过events返回，而select的传入参数也是传出参数。两者传出参数均表示发生事件的对应I/O标识。
两种方式的区别主要体现在以下几个方面：
select所能控制的I/O数有限，这主要是因为fd_set数据结构是一个有大小的，相当与一个定长所数组。
select每次都需要重新设置所要监控的fd_set（因为调用之后会改变其内容），这增加了程序开销。
select的性能要比epoll差，具体原因会在后续内容中详细说明。
嗯，说道这个为什么select要差，那就要从这个select API说起了。这个传进去一个数组，内部实现也不知道那个有哪个没有，所以要遍历一遍。假设说我只监控一个文件描述符，但是他是1000。那么select需要遍历前999个之后再来poll这个1000的文件描述符，而epoll则不需要，因为在之前epoll_ctl的调用过程中，已经维护了一个队列，所以直接等待事件到来就可以了。
Linux中select此段相关代码为：
/* 遍历所有传入的fd_set */
for (i = 0; i < n; ++rinp, ++routp, ++rexp) {
unsigned long in, out, ex, all_bits, bit = 1, mask, j;
unsigned long res_in = 0, res_out = 0, res_ex = 0;
const struct file_operations *f_op = NULL;
struct file *file = NULL;
in = *inp++; out = *outp++; ex = *exp++;
all_bits = in | out | ex;
/* 此处跳无需监控的fd， 白白的浪费时间啊…… */
if (all_bits == 0) {
i += __NFDBITS;
continue;
}
/* 后续进行一些相关操作 */
}
而epoll则无需进行此类操作，直接检测内部维护的一个就绪队列，如果队列有内容，说明有I/O就绪，那么直接赋值返回内容，成功返回，如果没有成功，那么睡眠，等待就绪队列非空。
通过这个两者的比较，其实两者的差距啊，大部分是因为这个API设计所决定的，select就设计成这样一个API，内部再怎么优化也只能是这么个烂样子，而epoll这样维护与等待分离，灵活多变，最后也就带来了相对的高性能，以及可扩展性。
