最近这一周都在忙kpush的项目,其实看名字大家也应该很容易联想到 jpush,确实名字相似,功能也是类似的。

kpush主要是用来解决app实时推送的问题。

有人要问,为什么明明有了jpush,百度推,还有各种大公司的推送,我还要自己写一个呢?

因为我实在受不了他们的某些限制。

  1. 表面免费,实际不交钱就会把你的到达率卡在某个值上永远上不去
  2. 限制太多,又是发送频率不能超过多少,又是哪些统计数据不交钱不能看
  3. 推送太慢,可能由于接入应用太多导致用户量级太大,所以他们不得不做了很多延时发送的处理,但其实对于小体量(百万连接左右)的应用来说,直接实时下发就ok了。套用某广告说的:我要的,现在就要!

而相对的,kpush特意解决了这些问题:

  1. 完全开源免费,随意部署
  2. 自带统计后台,看到真实的到达率和点击率
  3. 与客户端保持tcp长连接,并30秒心跳一次。所有推送消息均实时下发,不做任何延时。至于发送效率,瓶颈主要在gateway端,测试过200万链接发送也只需要几秒,所以对一般小体量的应用,部署一台kpush服务器完全够用。
  4. 支持分布式。如果真的用户量级很大(千万级),也可以轻松搞定

kpush服务器端也是基于maple来实现的。

github地址为: https://github.com/dantezhu/kpush

做了个简单的官网: http://kpush.cn

 

欢迎大家试用,或者去 http://kpush.cn/demo 体验一下。

29则回应给“新开源项目: kpush-开源的移动端Push解决方案”

  1. lf8289说道:

    “测试过200万链接发送也只需要几秒”, 请问下部署的服务器是什么配置呢,带宽是多少?

    [回复]

  2. lf8289说道:

    你好,我在push_helper.py文件的find_match_uids函数中看到有users = user_table.find(query_params, { “uid”: 1}),对于query_params是查询条件的dict,但是后面第二个参数{ “uid”: 1}是什么意思呢,难道是只获取uid为1的客户端吗?感觉应该不是啊?

    [回复]

    朱念洋 回复:

    看一下mongodb的api,那个是说只返回uid字段

    [回复]

  3. lf8289说道:

    给你反馈个问题, kpush/backend/kpush/local_config_example.py文件中:# mongodbMONGO_URL = ‘mongodb://admin:admin@127.0.0.1:27017/kpush’使用上面的MONGO_URL值,在访问http://127.0.0.1:5000/admin/是会出现500错误,会报出如下错误:OperationFailure: command SON([('authenticate', 1), ('user', u'admin'), ('nonce', u'bda8ca63ad6b851a'), ('key', u'1a3eefe560fb5fa31b8487c552af1ed1')]) on namespace kpush.$cmd failed: auth failed但是我把MONGO_URL更改为:MONGO_URL = ‘mongodb://127.0.0.1:27017/kpush’,就可以正常运行了。

    [回复]

    朱念洋 回复:

    你授权的问题 你试一下admin admin能否用mongo命令行登录

    [回复]

    lf8289 回复:

    不好意思,是我addUser时候,没有切换到kpush数据库上导致的。

    [回复]

  4. nemo说道:

    不错哦。小公司都搞开元项目,赞

    [回复]

  5. Astone说道:

    客户端保持 TCP 长链接真的好吗?1, 推送频率一般来说不是很高吧. 除非是 IM 那种2, 移动端的网络链接频繁断线是很正常的事, 长连接很容易断的吧.3, app 进入后台之后链接还在吗?

    [回复]

    朱念洋 回复:

    1. 不一定好,还是看实际应用场景2. 是的,所以还是要有心跳3. android的service回收时间说起来比较复杂,但是只是进入后台,连接是还在的。

    [回复]

  6. 说道:

    什么时候 能把离线功能给加上啊[good][赞][good]

    [回复]

    朱念洋 回复:

    离线功能要加其实挺简单的,要给用户做一个在线状态的存储,不过一直没时间做。。。看忙过这一阵去把

    [回复]

    Eric 回复:

    能说一下具体的思路吗,我也琢磨琢磨

    [回复]

  7. Eric说道:

    您好,能把推送流程简单描述一下吗,我现在不太懂的地方是,利用trigger告诉maple,有条消息要推到客户端.然后maple是怎么处理的,是交给worker做的吗?

    [回复]

    朱念洋 回复:

    [回复]

    Eric 回复:

    嘿嘿,谢谢回复,这几天看源码,也看出了一点感觉,什么时候能做个离线消息啊.或者简单叙述一下实现思路,我想尝试试试写写

    [回复]

    Eric 回复:

    看了很多国内的第三方推送,无意间看到一句话:”移动设备在线、离线的状态不是很严格,要确保消息能送达只能依赖客户端的应答.” , 你之前提到过要做一个客户端的在线状态存储,是否跟这个言论有冲突呢?

    [回复]

    朱念洋 回复:

    是这样子,不严格的意思是指,时间有延时。我们可以这样解决:
    1. epoll本身检测到的断线,一定是真的断线了
    2. epoll没检测到断线,但是心跳超时,也是断线。

    第二种就不是实时的了,不严格指的是这里。而之所以检测不到,有很多原因,比如突然关机,协议没来及的发送fin,或者突然wifi断电等等。

    [回复]

    Eric 回复:

    那做离线是否适合采用客户端应答呢,我觉得这个办法确实有效,但是觉得不够科学,像你所说,做一个用户的在线状态存储,我现在没有什么思路,不知道你具体的想法,能否简单描述一下吗?

    [回复]

    朱念洋 回复:

    你说的就是断线状态吧,存起来就好,用redis key value存储即可。

    [回复]

    Eric 回复:

    嗯,是断线状态。还是不太明白你的意思。场景是这样的:假如用户因为各种原因断了连接,后台进程杀死,断网之类,我如何保证下一次能把它断线状态是没有收到的消息让他重新获取。基于你的maple框架的

    [回复]

    Eric 回复:

    嘿嘿,今天终于把你的worker工作的代码给读懂了,发现要做离线还是有思路的,可不可以这么粗暴的理解,没有心跳的,全都是离线用户,储存到redis里,下次他们建立连接,就给这些用户第一时间推送他们错过的消息?

    [回复]

    朱念洋 回复:

    恩,可以按照这个思路来走,写的过程中可以及时修正。

    [回复]

  8. 蛋疼说道:

    onTimeoutCheck 这个有点问题

    [回复]

    朱念洋 回复:

    kpush还是maple?欢迎在github上提交request

    [回复]

  9. dsfdsf说道:

    无法正确删除已经过时的用户

    [回复]

    朱念洋 回复:

    maple.gateway已经在外网服务两年了,应该是不存在这个问题的,能具体一些?

    [回复]

  10. 反馈结果说道:

    ConnectionPool 线程池会触发两次释放,第一次主动断开触发一次 recycle,onTimeoutCheck 的时候又会触发一次 recycle,还有onTimeoutCheck ,我开了5个测试段,异常断开后,不能正确清除超时,队列里面一直是5个

    [回复]

    朱念洋 回复:

    我确认一下

    [回复]

    朱念洋 回复:

    我刚测试了主动断开和超时断开,都没有问题,你是在什么系统上测试的?32位还是64位?

    [回复]

发表评论