程序员的自我修养

阿里巴巴友盟+招人啦

0条评论38次浏览

公司简介

【友盟+】,全球领先的第三方全域数据服务商,通过全面覆盖PC、手机、传感器、无线路由器等多种设备数据,打造全域数据平台。秉承独立第三方的数据服务理念,坚持诚信、公正、客观的数据信仰,为客户提供全业务链数据应用解决方案,包括基础统计、运营分析、数据决策和数据业务等,帮助企业实现数据化运营和管理。

工作地址

北京市 朝阳区 北京国家广告产业园区

简历投递

hq90172@alibaba-inc.com,请以“应聘岗位-姓名”为邮件主题

前端开发专家

薪资待遇:20K-40K

工作年限:3-5年

职位描述:

  • 依据产品需求完成高质量的前端开发和维护;
  • 对具体的产品进行性能优化,实现极致的页面加载、执行和渲染时间;
  • 在理解前端开发流程的基础上,结合前端实际建立或优化提升工作效率的工具;
  • 在理解产品业务的基础上,提升产品的用户体验,技术驱动业务的发展;
  • 关注前端前沿技术研究,通过新技术服务团队和业务。

职位要求:

  • 精通各种前端技术,包括HTML/CSS/JavaScript/Node.JS等;
  • 对前端工程化与模块化开发有一定了解,并有实践经验(如RequireJS/SeaJS/KISSY等);
  • 至少熟悉一门非前端的语言(如Java/PHP/C/C++/Python/Ruby),并有实践经验;
  • 具备良好的团队协作精神,能利用自身技术能力提升团队整体研发效率,提高团队影响力;
  • 对前端技术有持续的热情,个性乐观开朗,逻辑性强,善于和各种背景的人合作。

JAVA专家

薪资待遇:20K-40K

工作年限:3-5年

岗位描述:

  • 参与友盟+平台系统架构设计与公共基础服务的开发工作,对平台的发展进行规划并推广到业务线落地;
  • 主导不同业务、技术改造类项目的系统分析、设计工作,承担核心功能、公共核心模块的代码编写,确保项目进度和质量;
  • 主导/参与系统性能优化、安全防护的解决方案的制定实施;
  • 主导/参与系统架构设计、接口规范制定、技术文档编写等。

岗位要求:

  • 计算机相关专业本科或以上学历,三年以上J2EE项目开发经验;
  • 有扎实的编程基础,精通java开发语言,熟悉jvm,web开发、缓存,分布式、消息中间件等核心技术;
  • 精通Java EE相关的主流开源框架,如Spring、iBatis、struts等。
  • 熟悉Oracle、MySql、MongoDB等数据库设计开发;
  • 熟悉Linux操作系统、SVN操作;
  • 具有较强的业务和数据敏感度,善于分析业务需求并提出解决方案;
  • 对技术有热情,学习能力强,具有良好的团队合作精神和开放的心态。

大数据研发专家

薪资待遇:20K-40K

工作年限:3-5年

岗位描述:

  • 负责数据平台的规划、技术选型和建设,包括但不限于数据存储、数据计算、数据仓库的规划和实施,研究跟进业界相关技术;
  • 深入理解数据业务,分析用户需求,负责业务计算的抽象和优化,能独立完成项目的系统分析、设计,并主导完成详细设计和编码的任务,确保项目的进度和质量;
  • 为客户特定计算需求提供解决方案,从用户角度推动业务发展;
  • 维护和升级现有软件产品和系统,快速定位并修复现有软件缺陷;
  • 能够有效地对新人或普通开发工程师进行辅导,帮助其快速成长;

岗位要求:

  • 熟悉数据仓库模型设计,具备数据加工处理(ETL)相关经验;
  • 至少熟悉一种关系型数据库如Oracle、mysql等,熟练掌握Hive/SQL,熟悉Hadoop/Map-Reduce/MPI分布式计算框架,有海量数据处理经验者优先;
  • Java/C++开发及设计经验,优秀的编程能力及良好的开发习惯;
  • 熟悉机器学习,自然语言处理,数据挖掘相关理论,熟悉各类算法使用场景,有实际大规模算法应用研发经验者优先;
  • 有云计算大数据产品应用经验优先;
  • 工作认真负责,有快速学习的能力,热爱数据,主动积极,有好奇心;
  • 具有良好的沟通、团队协作、计划和创新的能力。

算法专家

薪资待遇:20K-40K

工作年限:3-5年

职位描述:

  • 基于【友盟+】的全域大数据资源,充分挖掘数据价值,并将成果应用在各个垂直领域,例如数字营销,金融风控,智能推荐等;
  • 能够持续学习,保持跟进机器学习领域最新研究方向和成果,以及对数据应用新领域的探索;
  • 支持各业务部门和客户对于算法建模的要求。

职位要求:

  • 熟悉常用数据挖掘技术和机器学习算法,熟悉其原理和适用范围;
  • 熟练掌握的数据挖掘挖掘和机器学习的脚本和常用工具;
  • 在以下领域有深入研究经验者优先:
    • 用户行为数据的分析挖掘和用户画像的预测;
    • 垂直行业的数据挖掘经验(金融征信、游戏、旅游、新闻等);
    • 广告和推荐算法的研发与优化;
分类:未分类
标签:

第三方Web Push

0条评论145次浏览

最近在思考团队和个人下一步的方向,业务上一度确定准备做第三方web push,但一番调研下来,发现国内做的意义不大。这里把一些过程和结论记录下来吧。

什么是Web Push

"The Push API enables sending of a push message to a webapp via a push service. An application server can send a push message at any time, even when a webapp or user agent is inactive. The push service ensures reliable and efficient delivery to the user agent. Push messages are delivered to a Service Worker that runs in the origin of the webapp, which can use the information in the message to update local state or display a notification to the user."

简单来说,web push可以在关闭页面、甚至关闭浏览器的情况下,依然可以将消息下发到终端(这真是一个听着就神烦的玩意)。

为何出现web push?

主要还是和google大力推行PWA(Progressive Web Apps)有关。PWA是一种让网页长得和app一样的技术。然而想让网页和app具有同样的表达能力,一个比较大的问题就是:app有推送功能,网页如何实现?虽然h5定义了Web Notifications,可以询问是否允许推送、如果允许了可以推送消息,但那毕竟是需要页面打开的情况下才行。

于是google又推出了一个叫Service Workers的技术。如果把浏览器看成操作系统,把pwa站点看成运行在操作系统上的app,那么Service Workers就是pwa app在这个操作系统上的后台进程(其实就是一段隔离执行的js,当页面关闭的情况下依然能够执行一段时间,这段js可以定义接收到推送消息后的动作)。浏览器接收到服务端的推送消息后,根据Service Workers里面定义的动作,最后通过h5的Web Notifications api进行展示。

整个链路都通了后,web push就自然而然的诞生了。

什么是Web Notifications

Web Notifications是html5定义的一套api接口,主要用来询问是否允许消息通知、展示消息通知等。目前主流浏览器中,只有firefox、chrome、safari、opera支持。详细可以看这篇文章,介绍的很不错:简单了解HTML5中的Web Notification桌面通知
(更多…)

分类:Web Push
标签:

spark streaming一些坑爹事

6条评论2,103次浏览

kafka无限重连

现象

spark任务/kafka集群会隔一段时间出错,日志基本都会显示too many open files。查看socket连接会发现会有几千到几十万的连接。

仔细的查看spark的运行日志,会发现有如下错误:

我们的kafka中每个topic都是12个分区,对于连接1个topic的spark streaming任务,每次刷出上面的日志后,通过命令netstat -antup |grep 9092或者ss -atp |grep 9092会发现对应的spark任务的连接数又多12个。

排查

基本可以确定是连接没有正确关闭导致的,gitlab上看了下最近的改动:由于每个batch的处理时间接近batch的间隔时间,所以把处理逻辑全部放到了线程池中去处理。大概的代码如下:

回滚了这个改动后,日志不再刷出上面的错误日志,查看连接数也一直是固定的12,正好对应12个kafka partition。于是将代码改成:

然后一切都正常了。

从结果来看,真正去kafka读取数据是发生在读取partition变量内的数据时。若直接将partition变量放入线程池,则导致无法使用已有的连接,然后就会重新建立连接,而且在读取完数据后也没有正确的关闭连接,从而导致了上面的错误。

stopGracefullyOnShutdown

为了能优雅的关闭spark streaming,可以SparkConf.set("spark.streaming.stopGracefullyOnShutdown", "true")

然而坑爹的事情是,需要等到下一个batch才能优雅的关闭,不论当前的batch是否已经处理完。比如batch间隔是10分钟,每个batch处理时间是3分钟。若在10:00调用关闭任务的命令,spark不会在10:03执行完当前batch后关闭,而是直到下一个batch执行完才关闭,也就是10:13。对于batch间隔小于30s的倒是也能接受这样的设定,但对于10min这样的间隔,简直是无法忍受。

此外,还可以加上:

把stream当成集合

这里将永远也进入不了partition.foreach,因为partition.size会遍历一遍partition,而遍历一遍的stream就代表消费完毕了。╮(╯_╰)╭

分类:Apache Spark
标签:,

Hello Akka

0条评论621次浏览

关注akka有一段时间了,一直想在项目中用上,可惜没有合适的使用场景。

最近在做hbase的数据迁移,背景就不说了,反正很操蛋。最后的方案是dump全部的数据到磁盘上然后读取后写到新集群。

为了能尽量将rowkey分散开来,除了将region(startkey,endkey)的list打乱顺序外,还需要同时打开较多文件,每条记录随机写到某个文件中。这里终于用上了akka,避免了写的使用synchronized这样的方式。

Main函数,创建500个LogActor,每个LogActor写一个文件。采用RoundRobin的方式轮询写记录。Worker是具体读hbase的类,这里不贴代码。numOfReader为24,因为服务器的cpu core是24,设置大于24的值也最多24个并行。当然可以设置默认的最大值,但既然推荐最大值是cpu核心数那还是就按照推荐的来吧。

总结来说就是24个worker读取hbase的数据然后发送到某个LogActor写入到文件。

写记录只需调用Reader(recordToRandomWrite)即可。

LogActor代码:

第一个akka的实际应用,在此记录。

分类:Akka
标签:, ,

mongodb 集群迁移

0条评论1,696次浏览

问题:测试机上有一台全部运行在本地的mongodb集群。由于网络变化。现在本机的ip发生改变。因此 原来配置的绝对ip地址全部不可用。需要迁移。

简单版

  1. 每个sharding如果是replica set那么需要重新设置replica set的配置信息到新的ip地址。
    • 停止rs的所有副本。
    • 以standalone模式启动其中一个副本,修改rs.conf
    • 重复以上操作到其他所有副本
    • 重新以rs模式启动所有副本。查看rs的状态确认正确。
  2. 修改config server的meta信息为正确的ip地址。
    • 连接到config server 修改 config数据库下 shards集合里的关于sharding的地址为正确的地址。
  3. 重启 mongos 和 config server。

详细版

原有配置

  • mongos实例 x1:运行在192.168.6.81:20202
  • config server实例 x3:运行在192.168.6.81:36000, 192.168.6.81:36001, 192.168.6.81:36002
  • 三副本replica set实例 x2: 分别运行在 sh0/192.168.6.81:23000,192.168.6.81:23001,192.168.6.81:23002 和 sh1/192.168.6.81:24000,192.168.6.81:24001,192.168.6.81:24002
  • replica set sh0和sh1已经添加为mongos的两个分片

(更多…)

分类:MongoDB
标签:,

架构师做什么?

0条评论858次浏览

记得我最早思考这个问题的时候还在国企,那会刚参加工作没多久。某天突然看到有人的职位是架构师,于是很好奇,作为一个架构师,他/她的日常工作是做什么?或者这么说,你要能够做些什么,才能成为一个架构师?

然而,作为一个低端码农,对这个问题一直无解。而且还受到国企那些架构师的影响,一度以为架构师就是一群没能力做开发,只会满嘴空炮,开一个又一个浪费生命的会议,写一堆自己都不愿看第二遍的文档的复制粘贴机器。

前几天梳理后端架构,过程中有很多想法,例如这里当初这么设计不是没事找事?这样设计这个模块岂不是没法扩展?当初要是不这样设计现在工作量岂止减少10倍?!突然间我意识到,架构师的工作,是不是就是处理这样的事情——让系统/服务/产品等后期更容易维护/扩展,不至于被后来者诅咒?

程序员为自己写的代码负责,为自己弄出来的bug买单。除此之外,一个系统/服务/产品是否就没有其他方面的问题了?比如程序员按照设计用redis来缓存数据,现在内存不够用了,是程序员的锅吗?当初采用了http+json作为内部通信协议,现在随着业务增长和新的需求,发现http+json的效率更不上了,是谁的锅?某个mysql表的字段设计成了text,导致现在稍微大量点的写入就主从延迟超过阈值,这是谁的锅?

诸如此类,或大或小、或轻或重的问题,我想应该就是架构师来处理的吧。

对于架构师做什么,现在只有这点浅薄的认知,希望以后成为架构师(不是国考的系统架构师)后再写文章补充吧。

如何成为架构师?我觉得除了脑子必须特别好用这种基本要求外,还需要丰富的经验和特别广的知识面,而且需要专精一两个领域。

比如你得知道kafka作为MQ,可靠性有多少,TPS/QPS有多少,作为整个系统的消息中心,是否可以信赖;

你得知道redis的QPS和TPS是多少,是否会因redis存在瓶颈,如何设计key可以方便从单机redis扩展为集群,或者小集群扩展到大集群。

你得知道http/thrift等通信协议的优缺点,不同场合做出不同的选择。

你得知道mysql能撑住的量是多少,字段类型设计成什么样能满足需求又不失性能。

你得知道hbase、mongodb试用什么场合,都有什么坑。

你得知道响应N万QPS http请求需要什么样的框架,需要几台机器。

你得知道处理流数据storm和spark应该选哪个。

如何高可用?需不需要冷备热备?如何监控报警?系统中某个节点挂掉怎么办?服务解耦到哪种粒度?

是否所有需求都应该满足?哪些需求可以判定为不合理需求?
......

(以我目前的见识和经历,也只能想到上面这些。[捂脸])

等一系列的事情,这样才能在设计阶段,就能看到以后可能遇到的坑。

这里再记录下现在工作中遇到的一些坑:

  • mysql的某字段设计成为text,实际上设置成为varchar完全能够满足。text导致主从延迟十分大。如何确定的?弄了另外一张完全一样的表,将text改成varchar,就完全没有主从延迟了。但现有数据量太大,改变字段类型起码会锁表30分钟以上,完全不可接受,最后只能切换到另外一张表才解决问题。
  • 无效devicetoken存放在单机redis中,设计成为以app为key的set,某些巨型app的无效devicetoken可能上千万。后来单机redis的qps满足不了高峰期的查询需求,只能改成集群redis。但现有的key设计导致同一个app的数据只能存在一台redis上,根本解决不了问题,高峰期压力无法分散开来。最后将key设计成appkey+devicetoken的形式才解决问题。
  • redis集群的proxy问题。最开始我以为codis/twenproxy的proxy和hbase的master/zookeeper一样,不负责数据传输,只负责存储些meta信息,真正的数据交互式client和实际worker交互。结果发现只有一个proxy的情况下,qps和单机一模一样。后来进一步了解到原来proxy是要进行数据传输的,想要提高qps就得增加proxy数量。比如4台redis组成的集群,需要4个proxy才能发挥出全部的性能。
  • 同样的mongodb的proxy(mongos)也进行数据传输,后来全部改成多个proxy了,既发挥出了集群的全部性能,又消除了proxy的单点故障。
  • alias和tag的设计问题。这个就涉及到具体的业务了,大致的情况就是对这2个接口没有做任何的限制,基本的长度限制都没有,导致开发者/黑客滥用接口,alias库里面各种超过4MB长度的数据,有的甚至把整个网页当成alias,有的全部是各种攻击注入sql。而更多的开发者弄不明白alias和tag的区别,把两者混用,把tag当成alais,导致后端查询压力巨大,把alias当成tag,导致数据库完全存储不下。这个问题至今没有完美的解决方案,当初设计上的想法是好的,可不是每个用户都是按照设计的想法来的。永远不能小瞧用户的创造力/破坏力。从最开始,就应该有严格的限制来引导开发者正确的使用各个接口。没有限制往往带来的是灾难。
  • 存储在redis中的数据没有设置ttl。当初选择将数据存放在redis时就应该考虑到ttl。现在的结果是接近1T的数据,用了9台价值7-8W的机器,存放在redis集群中。而这个集群的qps是多少?1W都不到!一台redis就可以满足qps,但因为历史数据无法删除,导致只能不断扩展集群大小。根据dau等其他方面推测,这接近1T的存放在redis中的数据,最多只有30G的数据是有效的数据。
  • 没有防爆量设计。每个集成了sdk的app都会在一些事件的触发下发送http请求到服务器上。而有的集成有误的app可能会导致请求量暴涨到服务端无法处理的地步,可能只是log文件就能撑爆硬盘。这个问题到现在也没有解决,现在每次遇到爆量都只能硬编码。其实解决起来很简单,方案我也出了,但因为一年可能都遇不到两三次爆量,所以老大就一直觉得无所谓不用浪费时间开发这个功能。
  • 定时任务太多。很多业务数据都靠定时脚本上传数据到hdfs上再计算,每当遇到新增服务到新机器,服务转移到其他机器等情况,就会出现忘记部署定时任务的情况,从而导致业务数据计算有误差。现在解决方案是所有需要上传的数据写kakfa(实际上本来就会写kafka),然后后端spark streaming消费并写到hdfs上。干掉所有定时任务真是一身轻松。
  • 不合理的需求应该拒绝。某汪*带盐的网站家的app,大概累积设备量不到30W,每次广播打开数在7000左右。就算这7000个打开都在同1秒,那他们的服务器的qps也不过7000,况且这7000个打开是24小时甚至更长时间内陆续打开的。就这样的压力,他们就受不了了,要求我们把发送速度降到100/s。如果真的降到100/s正常情况下也就不到10s能发送完的任务我们需要40min才能发完,这意味着一台服务器在40min里只能龟龟龟龟速的发送这个任务。为了这个需求修改服务?我觉得除非吃多了,不然绝对不可能满足这样的需求。然而,我觉得的没用,你们懂的。[大哭]
分类:杂七杂八, 随想
标签:

玄学出奇迹

1条评论1,217次浏览

2016-11-03开始,APNs HTTP/2 API速度突然变得奇慢无比,建立连接各种超时,handshake各种超时。50个channel的情况下每秒能发送的消息只有个位数。简直哔了狗了。

初步排除一番后,发现10台服务器当中只有5台服务出了上述问题,另外5台的发送速度居然比平常还要快。于是怀疑集团为了双十一把网络调整了,让pe联系集团网络部的查了一通,返回结果,并没有任何调整。

接着怀疑是不是这五台机器的硬件出问题了,又查了一通,发现并没有。

最后怀疑程序出问题了。为啥最后才怀疑程序?我这服务线上无故障跑了好几个月了,突然出问题,还是几台机器在同一时间出问题,打死我都不相信。结果也表示,程序没有任何异常。

最后只能让苹果背锅了,认定是苹果的APNs HTTP/2 API服务抽风了,和这5台服务器命中相克。于是只能将大部分发送任务放到老版本API上去,少部分流量放到APNs HTTP/2 API上,然后关闭了出问题的那5台机器。

经过3天的观察,发现之前认为没有问题的另外5台服务器居然也出现了同样的问题。又是各种查后无果。期间抓包发现居然有高达20%的网络重传。

就在我即将崩溃,准备裸奔释放情绪的时候。突然间无意的发现,貌似这些发送比较慢的任务的remote ip地址第三位比较集中。苹果服务器ip前两位是固定的17.188。而那些发送比较慢的第三位基本上都是12X、13X以及少量的14Y(y<4)。难道是巧合?于是把所以机器上的所有发送慢的任务的ip全部查了一通,发现居然没有一个反例。于是我不由自主的得出一个玄学结论:remote ip第三位比较小的(比如小于145)发送速度慢,大于145的发送速度快。为了验证我的猜想,我又把所有服务器上的所有发送速度快的任务查了一遍,发现卧了个槽,居然还是没有反例,没有一个例外能推翻我的玄学猜测。

然后我将所有的结果汇总,发现remote ip第三位小于等于142的速度奇慢,各种超时,而且没有例外。而第三位大于等于144的速度奇快。然后让pe那边分析了一下抓到的包,发现20%的网络重传也全部都是remote ip第三位小于等于142的ip。进一步证实了我的玄学猜测是正确的。

接下来,修改程序上线,不连接那些remote ip第三位小于等于142的。经过1天的观察,卧槽,真的没有一个慢的任务。

对此我只想说,玄学出奇迹。

至于为何会这样,我只能猜测要么苹果的这2组ip地址的服务器在不同机房,有一个机房出了问题;要么就是苹果在灰度测试新的服务,因为抛开那些发送速度离奇慢的任务,其他的任务发送速度都翻了2-3倍。然而苹果官网上找遍了也没有一个公告什么的。

什么是玄学?玄学就是,今天编程不宜面朝东面,不然bug多;今天不宜上线,不然服务必挂之类的迷信。
1

分类:APNs
标签:,

Redis设置密码的那些坑

2条评论1,017次浏览

最近集团安全部扫描到我们组的redis没有设置密码。如何扫描的?一个脚本,登陆到服务器上查看固定路径下的redis配置,没有配置密码就被扫出来。简单无脑暴力。

于是开始虐心的添加redis密码之旅。

Server端配置

方法1:redis-cli -h xxx -p xxx CONFIG SET requirepass xxx

方法2:修改redis.conf文件,配置requirepass

对于twemproxy,可以升级到最新版本,然后配置redis_auth xxx。

Client端配置(Jedis)

项目中都是用的JedisPool。我们的方案是给所有代码进行如下处理:

看起来应该没问题,实际上测试了下,也一切ok,于是开始了第一次改密码尝试。将涉及到的七八个应用、几十处代码全部修改完毕上线后,一切正常。然后redis server端添加密码,瞬间崩溃了四五个服务,只剩两三个服务正常运转。于是立马去掉密码,开始查原因。

JedisPool初始化的坑

经过一轮排查,发现出问题的服务都是用的上面的方式初始化JedisPool。而没有出问题的都是下列方式初始化:

然后看了下源码,果然在有database参数且不等于0时,会进行一次select操作,而我们的password用的是null,所以就会报错。于是又一次将涉及到的七八个应用、几十处代码全部修改完毕,开始第二次改密码尝试。所有应用上线后,一切正常。开始redis server端添加密码,瞬间又是几个服务崩溃,几个服务正常。于是立马去掉密码,开始第二次查原因。

setTestOnBorrow的坑

又一轮排查后,发现出问题的服务都是JedisPoolConfig::setTestOnBorrow(true),没有出问题的要么是设置为false,要么是没有设置,而没有设置的默认情况下就是false。然后再次看了下源码,setTestOnBorrow应该是从pool中获取到实例的时候会去ping一下,然而此时没有auth过,于是又报错了。无奈,只能将所有的JedisPoolConfig::setTestOnBorrow(true)注释掉,开始第三次尝试。

还好,没有其他幺蛾子了,这次终于没有问题,加上密码,去掉密码,服务都正常运转。心塞。

分类:Redis, 战5渣
标签:,

APNs http2接口速度调优

2条评论1,720次浏览

第一招:釜底抽薪

简介:通过去除无效devicetoken,本地减少发送数,来提高整个任务的发送速度。

有效性:视app决定,有的app卸载用户少,作用不明显,有的app卸载用户90%以上,效果杠杠的。

什么样的devicetoken是无效的,如何识别?简单来说apns返回发送失败时,reason内容为BadDeviceToken和Unregistered的可以判定成无效devicetoken。关于BadDeviceToken很好理解,而Unregistered又是个什么鬼?有如下测试:

  1. 关闭推送,1小时内发送消息,apns返回success,但是app没有收到消息
  2. 打开推送,在关闭期间发送的消息收不到,打开后的消息正常收到。devicetoken没有变化
  3. 关闭推送,第二天发送消息,apns返回success,但是app没有收到消息
  4. 第二天打开推送,在关闭期间发送的消息收不到,打开后的消息正常收到。devicetoken没有变化
  5. 卸载后,立马发送消息,apns返回Unregistered
  6. 重装后,生成新的deivcetoken,对老的deivcetoken发送消息,apns返回success,但是app没有收到消息;对新的deivcetoken发送消息,apns返回success,app收到消息

以上测试基于ios9,ios10还没测试。不过根据历史发送结果来看,Unregistered十有八九就是被卸载了。

第二招:调虎离山

简介:使用netty的发送程序,可以尽量将耗时的代码从EventLoopGroup中移出,或用线程来处理。

有效性:视代码时间开销而定。

最近在弄美国服务器进行发送速度的测试,测试结果后面说。过程中发现,读取/写入国内的redis速度慢的令人发指,导致发送速度不到10条/秒。于是将可以异步处理的写入redis放到线程中去处理了(读取直接删除,反正是测试)。结果发现速度突突突突突突的快。于是国内也将写入redis做了相同的处理,虽然速度提升不是太明显,但总体的感觉还是快了一些。之前想着读写redis肯定非常快,不会造成多少时间开销,但从结果来看还是不能想当然。

第三招:无中生有

其实和无中生有半毛钱关系都没有,只是三十六计里面找不到合适的随便选了个。

简介:提高发送的并行度。

  1. 单服务器模式下增加channel的个数。
  2. 大型任务则分发到多个服务器上去执行。至于如何实现调度、如何统计结果、如何处理子任务失败、如何处理长尾问题、如何处理XX问题就不在这里讨论了。

反正自从我实现完多机器并行处理一个任务后,再也没有开发者反馈我们发送速度慢了[大哭]。比如以前慢的时候40分钟、快的时候7分钟发送完的任务,现在变成快的时候90s、慢的时候10分钟。好想给我自己一个赞。

终级大招:走为上计

去美国搞台服务器,性能不用多牛逼,内存够用、cpu还行,虚拟机也可以,速度就是一个突突突突的快啊,同样的程序,速度是国内的10倍以上。还考虑什么分布式调度、考虑什么子任务单点失败、考虑什么长尾、考虑什么结果汇总,麦什么破、锐什么丢死,直接突突突突的单线程都比国内快,就是这么暴力。

最后

速度调优什么的最讨厌了,懒得弄?很简单,来用友盟push,分分钟带你突突突突。

怎么感觉变广告贴了,摔!

分类:APNs
标签:

战5渣系列——Scala map()

1条评论1,060次浏览

Twitter的Scala School上面对map()函数介绍如下:

Evaluates a function over each element in the list, returning a list with the same number of elements.

Scala官网上面的介绍:

Twitter的解释是对一个list的每个element作用一个function,并返回数量相同的list。Scala官网则只说对一个collection的每个元素作用一个function,并返回一个新的collection。

对于只认真看过Scala School的我而言,map的作用就是对一个collection的每个元素作用一个function,并返回一个相同大小的collection。[哭笑不得]
(更多…)

分类:Scala语言, 战5渣
标签:,
profile
  • 文章总数:81篇
  • 评论总数:241条
  • 分类总数:32个
  • 标签总数:45个
  • 运行时间:1253天

大家好,欢迎来到selfup.cn。

这不是一个只谈技术的博客,这里记录我成长的点点滴滴,coding、riding and everthing!

最新评论
  • Anonymous: :?: :razz: :sad:
  • Anonymous: 牛
  • Anonymous: 楼主你好,我偶尔也会 遇到Reconnect due to socket error: java.nio.channels.ClosedCha...
  • Anonymous: sdfs
  • Anonymous: :arrow: :neutral: :cry:
  • Anonymous: java.io.NotSerializableExcepti on: DStream checkpointing has been enabled but the DStreams with their...
  • wick: HI,请问一下,U,S,V得到 ,怎么得到近似矩阵 (用spark java),谢谢。
  • Michael Whitaker: Thank you for this blog, it was very helpful in troubleshooting my own issues. It seems that no...
  • Anonymous: :mad:
  • Anonymous: :???:
  • Anonymous: :mad: :mad: :mad:
  • 洋流: 哥们,我问个问题,你 把testOnborrow去掉了。。 如果得到的jedis资源...
  • 洋流: 哥们,我问个问题,你 把testOnborrow去掉了。。 如果得到的jedis资源...
  • Anonymous: :razz: :evil: :grin:
  • 张瑞昌: 有很多,比较常见的是 Jacob迭代法,一次迭代O (n^3),迭代次数不清楚 ...
  • Anonymous: :mrgreen:
  • lc277: 你好 我想问下一般删除节点 要多久,要删除的datano de大概用了1t,解除...
  • Anonymous: 你好 我想问下一般删除节点 要多久,要删除的datano de大概用了1t,解除...
  • Anonymous: :smile: :grin: :eek:
  • 李雪璇: 想要完整代码,可以帮 忙发给我吗