`
文章列表
1 为什么需要全平台推送? 设想你有一个很棒的应用。以电商为例,用户搜索了一些产品,后来又放入了购物车。你的服务器记录了用户的这些行为,发现他可能会对某类商品感兴趣。而这类商品又刚刚新添加了一些特别炫的新货,不需要用户再次查询,应用会立刻通知给用户:“嘿,瞧瞧这新东西,也许你会喜欢!”。从技术角度怎么实现呢?显然我们需要一个push服务。相对Pull的方式,Push不仅仅能更实时的提供信息,更省电,而且基于server端强大的数据挖掘能力,push可以主动的发现和提供更多的有用信息,对用户来说,这很cool;对公司来说,这是商机。   移动互联网全平台是包括IOS,Android,Wind ...
某厨师出身的美食家说:“苏帮菜”的命根就是甜。这就是美食家和厨子的差别。哪个“苏帮菜”厨子不知道做“苏帮菜”要放糖呢?但是如果上升到上面这句话的高度,就可以是美食家了。   从码农上升到架构或者是技术主 ...
前言 为防止成为标题党,首先定义一下什么是大型网站, (1)业务依赖多,一个业务流程,需要调用多种资源,Memcached/DB/其他模块等等; (2)业务快速增长且不平均,比如电商网站中某一类产品增长特别明显; (3)并发 ...
  前言 作为在线系统负责人或者是一个技术专家,你可能刚刚接手一个项目就需要处理紧急故障,或者被要求帮忙处理一些紧急的故障,这个时候的情景是:(1)你可能对这个业务仅仅是听说过,而不怎么真正了解;(2)你可能没有这个故障的详细信息,比如可能仅仅是有使用方反馈服务中断了10分钟;(3)你对代码细节还没有仔细研究过。   这个时候该怎么解决问题呢?根据以前的经验,工程师们常常倾向于直接登上服务器检查代码,试图立刻修改问题。或者是把某些可能是问题的配置做修改,但并不是100%确认这就是问题的根本原因。但结果往往是在解决问题的同时引入了新的问题,或者是没有找到问题的根本原因,导致用户的再次投诉。 ...
在浏览了诸多中文Scribe+log4j的博客之后,我发现,大家都是很不要face的抄人家的文,却没有一点要引用原文的意思。估计是抄来抄去,抄的多了都想不起来是谁抄谁的了。   原作应该是 Alex Loddengaard 的大作,写的很清楚,而且还有代码。这里不需要画蛇添足,大家欣赏吧。 Configuring and Using Scribe for Hadoop Log Collection http://www.cloudera.com/blog/2008/11/configuring-and-using-scribe-for-hadoop-log-collection/   ...
Jetty Continuation实现原理和使用场景分析 Jetty continuation是什么?简单的说,就是用一个NIO模拟http同步连接。我们都知道http请求时同步的,就是说http request发送到server之后,server分配一个单独的线程处理这个请求,请求完成之后再返回response给请求端。这个过程中server处理线程一般是不释放,即使是什么都没有干。更关键的是承载http请求的tcp socket是阻塞式的。显而易见的是如果这个请求时间较长,不但server threads被占用而无法处理新请求,仅仅是并发连接数的问题就让人头疼。 Jetty Conti ...
  分库分表是解决mysql水平扩展的主要手段。网上有关策略的讨论很多,主要是hash扩展、按时间扩展、按范围扩展等等。但真正想实施分库分表的朋友们往往觉得“策略听来终觉浅,觉知此事要代码”,因此本文的主要目的是给朋友们提供一个可实现架构。 JDBCTemplate和Hibernate 大家都知道Hibernate是ORM(对象-关系数据库 mapping)意义上的第一个真正的“统治级”产品。JDBCTemplate则是对Spring对jdbc的简单封装,相对于Hibernate,工程师需要自己写sql,而不是像Hibernate那样直接操作对象解决数据库持久化的问题。因为暴露了sql,J ...
  cache是老生常谈的事情,这里我想强调一下KISS原则,就是keep it simple and stupid。最近看到很多场景下cache使用的不适当,特别是被过度使用了。一个简单键值存储并不需要复杂的cache方案,好的方案就是用最简单的方法解决问题 ...
分布式服务部署在多台机器上,统一查看日志是个很重要的需求。对日志量很大的应用,为不影响生产系统,可以通过thrift、protobuf等方式收集到日志中心,再使用hadoop+lucence进行分析。实时日志分析也可以用这个系统。最近团队在预言这个方案,以后有机会再和大家分享。而基于gearman的分布式日志查询系统,知识资源投入小,效果却很强大,可以有效处理在线debug的问题,把工程师从海量日志里解放出来,十分推荐。   另外要说明的是,gearman主要侧重于分布式任务指派。不要让gearman做它不擅长的事情,比如在gearman worker中返回大量计算结果等。这些通讯工作完全可 ...
最近一年经历了很多业务快速增长的情况,早期对容量的规划不足成为普遍现象,需要在实际业务中要不断调整。这就涉及到服务扩容。一般无状态请求的扩容,比如varnish转发http请求,因为不需要考虑状态迁移造成的问题,比 ...
Twitter的核心队列Kestrel使用Netty作为通信模块,从另一个角度证明了Netty的性能和健壮。 Netty是否比MINA强?从底层实现,两者几乎差不多,但Netty的优势是从架构上采用事件通知机制,真正的将异步模式引入来解决各种场景。响应时间可能会加长,但优势在于系统之间的依赖减弱,自身处理能力的决定因素自封闭(瓶颈可以直接根据自身业务处理资源消耗情况估计出来)   我们看看Twitter是怎么用Netty。Twitter很多项目都是用scala写的,scala是很简洁的语言,直接运行在jvm上。可以直接调用Java类。下边的代码都是来自Twitter的核心队列项目Kestr ...
一直以来比较关心高性能通讯模块的设计,最近看到两篇好文,由此想到曾经参与的几个通讯模块的设计和实现,跟大家分享思路。   首先来分享好文: http://agapple.iteye.com/blog/859052 这一篇讲得是google protobuf协议和其他序列化的性能测试。朋友们看了一定会砰然心动,protobuf如此之高的通讯效率当然是求之不得。新浪微博IM各模块之间也采用protobuf作为通讯协议,TimYang写过文章比较google protobuf和facebook Thrift之间的性能。也证实了protobuf还是好东东。加之MINA可以很好的和此类通讯协议 ...
前面写过一个博文高:高吞吐高并发Java NIO服务的架构,http://maoyidao.iteye.com/admin/blogs/1149015 。这个架构是和MINA一致的,或者可以说MINA是基于同样的思路构架的。想阅读MINA源代码的朋友可用参考这个架构来研究MINAsource code。但是考虑到在已经有比较可靠的开源实现的情况下,现在朋友们很少会自己去实现一个NIO模块。就想到把它做成一个系列,第一篇主要是讲解一种业内普遍采用的NIO架构,及其架构上的两个要点,即:1. 基于提高的性能的线程池设计;2. 基于网络通讯量的通讯完整性校验。这一篇来讲讲在基于MINA搭建高性能NI ...
小型项目对于数据库的使用往往比较随意,过多的考虑分库分表等策略对于相当多数没有海量数据需要存储到db的应用又显得浪费。那么如何避免,特别是当数据库压力比较小的开发初期,db架构方面的问题,我想遵循几个简单的原则就可以。从应用架构的角度,项目中最常见的问题有三种:如何使用数据库,NULL值,索引与查询。 一,如何使用数据库 1,围绕数据库的使用方式也决定架构如何。正如“MySQL数据库开发的三十六条军规”开篇所说: •别让脚趾头想事情 •那是脑瓜子的职责 •让数据库多做她擅长的事: 尽量不在数据库做运算 复杂运算秱到程序端CPU 尽可能简单应用MySQL 这么简单的道理,却曾在项目里被 ...
Java NIO成功的应用在了各种分布式、即时通信和中间件Java系统中。证明了基于NIO构建的通信基础,是一种高效,且扩展性很强的通信架构。基于Reactor模式的高可扩展性架构这个架构的基本思路在“基于高可用性NIO服务器架构”( ...
Global site tag (gtag.js) - Google Analytics