<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[移动互联网后端技术]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/iteye_15264</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; iteye_15264]]></copyright><item><title><![CDATA[Dropbox协议分析]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82486964</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82486964</guid><author>iteye_15264</author><pubDate>Fri, 12 Apr 2013 00:15:16 +0800</pubDate><description><![CDATA[
 
http://eprints.eemcs.utwente.nl/22286/01/imc140-drago.pdf
本文观点基于以上paper
 
相信不是所有同学都了解Dropbox，先做一个简单知识普及，Dropbox是一个提供同步本地文件的网络存储在线应用。支持在多台电脑多种操作中自动同步。并可当作大容量的网络硬盘使用。
 
在展开之前先回答一个问题，我们为什么要关系Dro...]]></description><category></category></item><item><title><![CDATA[Memcache架构新思考]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82486957</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82486957</guid><author>iteye_15264</author><pubDate>Thu, 11 Apr 2013 23:28:04 +0800</pubDate><description><![CDATA[
 
2011年初Marc Kwiatkowski通过Memecache@Facebook介绍了Facebook的Memcache架构，现在重新审视这个架构，仍有很多方面在业界保持先进性。作为weibo内部数据处理量最大，对数据延迟最敏感的部门，基于本厂2年多来对mc的使用心得，我在本文总结对MC架构的一些新思考。
 
1. Memcache使用中的雷区
通常你可能考虑不到，但又隐藏在某处...]]></description><category></category></item><item><title><![CDATA[Memcached for移动互联网：mcperf压测1k~10k数据笔记]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82452443</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82452443</guid><author>iteye_15264</author><pubDate>Mon, 31 Dec 2012 18:56:28 +0800</pubDate><description><![CDATA[移动互联网场景中随着人机交互方式的改变，用户数据也发生了比较大的改变。从以1k以下的文本为主数据，变为1k~10k的音频占很大比例的数据。响应的后端服务的队列、存储、缓存也需要做一系列针对性调整。这里就简单记录一下maoyidao对Memcached的压测情况。
1. 压测工具：mcperf
mcperf使用简单，输出报告清晰。最初是twitter为了证明其Twemcache在特定场景下（需要...]]></description><category></category></item><item><title><![CDATA[通讯系统经验谈【三】解读内核参数 - sysctl.conf]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82448202</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82448202</guid><author>iteye_15264</author><pubDate>Mon, 10 Dec 2012 23:34:54 +0800</pubDate><description><![CDATA[在上一篇中http://maoyidao.iteye.com/blog/1744309，主要介绍了和系统资源限制相关的参数。本文是通讯系统经验谈的第三部分，继续解读和系统性能相关的内核配置。
 
上篇介绍了和系统设置有关的几个参数，在一台系统上，连接到一个服务时的本地端口是有限的。由于端口是16位整数，也就只能是0到65535，而0到1023是预留端口，所以能分配的只是
1024到65534...]]></description><category></category></item><item><title><![CDATA[通讯系统经验谈【二】解读内核参数 - socket/文件句柄资源限制参数]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82448065</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82448065</guid><author>iteye_15264</author><pubDate>Mon, 10 Dec 2012 13:41:55 +0800</pubDate><description><![CDATA[在本系列的第一篇（http://maoyidao.iteye.com/blog/1744277）中介绍了TCP状态以及服务器上常出现的TIME_WAIT和CLOSE_WAIT状态的成因、影响和解决方法。本篇主要解读在一台并发15万连接的HTTP服务上的系统配置
 
Linux系统资源限制
1. 最大文件数
查看进程允许打开的最大文件句柄数：ulimit -n
查看进程所占的文件描述符： ...]]></description><category></category></item><item><title><![CDATA[通讯系统经验谈【一】TCP连接状态分析：SYNC_RECV，CLOSE_WAIT，TIME_WAIT]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82447873</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82447873</guid><author>iteye_15264</author><pubDate>Sat, 08 Dec 2012 23:58:50 +0800</pubDate><description><![CDATA[面试时看到应聘者简历中写精通网络，TCP编程，我常问一个问题，TCP建立连接需要几次握手？95%以上的应聘者都能答对是3次。问TCP断开连接需要几次握手，70%的应聘者能答对是4次通讯。再问CLOSE_WAIT，TIME_WAIT是什么状态，怎么产生的，对服务有什么影响，如何消除？有一部分同学就回答不上来。不是我扣细节，而是在通讯为主的前端服务器上，必须有能力处理各种TCP状态。比如统计在本厂的一...]]></description><category></category></item><item><title><![CDATA[架构师笔记【杂】cache/容量及带宽规划/sysctl.conf配置等]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82447137</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82447137</guid><author>iteye_15264</author><pubDate>Wed, 05 Dec 2012 13:31:58 +0800</pubDate><description><![CDATA[ 
不知道什么时候记得一些笔记，现在翻出来看看还是很有启发。也不想整理了，格式有点乱不过反映了当时的一些思考。
好的架构时演进出来的而不是从石头缝里蹦出来的，需要我们在工作中不断的思考、总结、实践。。。
 
1. 有关架构师的思考，从模块间的耦合关系上考虑
A，健康状况大致为多少线程、db每port写入量为多少，多少server，带宽占用，请求频率；
B，如果峰值情况怎样？
C，如前...]]></description><category></category></item><item><title><![CDATA[通过NIO实现Memcached multi get]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82446237</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82446237</guid><author>iteye_15264</author><pubDate>Fri, 30 Nov 2012 23:58:48 +0800</pubDate><description><![CDATA[

Memcached（简称为：MC）在互联网广泛使用，是最基础的架构。但MC的mget（即一次获取多个值）一直是一个难题，我们的要求是mget性能上要尽量接近普通memcache get。下面通过一段伪代码介绍了如何以接近get single value的性能实现mget，并且就该架构在实际环境中遇到的一些问题加以讨论。
场景
在开始这个话题之前先考虑一个问题，为什么需要MC mget？R...]]></description><category></category></item><item><title><![CDATA[构建高性能服务（三）Java高性能缓冲设计 vs Disruptor vs LinkedBlockingQueue]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82404258</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82404258</guid><author>iteye_15264</author><pubDate>Sun, 26 Aug 2012 15:52:04 +0800</pubDate><description><![CDATA[一个仅仅部署在4台服务器上的服务，每秒向Database写入数据超过100万行数据，每分钟产生超过1G的数据。而每台服务器（8核12G）上CPU占用不到100%，load不超过5。这是怎么做到呢？下面将给你描述这个架构，它的核心是一个高效缓冲区设计，我们对它的要求是：
1，该缓存区要尽量简单
2，尽量避免生产者线程和消费者线程锁
3，尽量避免大量GC
缓冲 vs 性能瓶颈
提高硬盘写入I...]]></description><category></category></item><item><title><![CDATA[高性能RPC over MINA&google protobuf 代码&实例 （二）]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82402068</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82402068</guid><author>iteye_15264</author><pubDate>Sun, 19 Aug 2012 18:32:17 +0800</pubDate><description><![CDATA[在本系列上篇http://maoyidao.iteye.com/blog/1636923 实现了基于google protobuf的序列化反序列化，现在看看怎么把他们组装到MINA的nio中。本篇主要描述怎么处理断包。
 
使用MINA的CumulativeProtocolDecoder是个好主意，先从MINA自己的sample开始。在这个例子中如果接受到的IoBuffer只包含一部分消息， ...]]></description><category></category></item><item><title><![CDATA[高性能RPC over MINA&google protobuf 代码&实例 （一）]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82401894</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82401894</guid><author>iteye_15264</author><pubDate>Sun, 19 Aug 2012 01:41:52 +0800</pubDate><description><![CDATA[最近团队在开发基于移动互联网的项目，又一次涉及到post service，即在服务器集群之间投递消息。是的，又是一个RPC服务。RPC实现方式从笨重的CORBA，SOAP over HTTP，XMPP over TCP，到轻量级的protobuf，scribe和Avro。这里不想比较各自的应用场景（另外后面三种RPC方式极为接近，都是通过提供Object &amp;lt;-&amp;gt; 二进制映射来提高高效的...]]></description><category></category></item><item><title><![CDATA[在HBase中应用MemStore-Local Allocation Buffers解决Full GC问题：第二部分]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82368124</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82368124</guid><author>iteye_15264</author><pubDate>Mon, 09 Jul 2012 22:06:58 +0800</pubDate><description><![CDATA[
 
maoyidao注：上个月写了一遍博文，介绍一种高效的Java缓存实现，http://maoyidao.iteye.com/admin/blogs/1559420。其本质是模仿Memcached的Slab，通过分配连续定长的byte[]减少大规模使用Java Heap作为缓存时不可避免的GC问题。虽然当时构思和实现这一思路时并没有参照其他开源产品，但这一思路在很多著名的开源产品上也有类似...]]></description><category></category></item><item><title><![CDATA[在HBase中应用MemStore-Local Allocation Buffers解决Full GC问题：第一部分]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82364168</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82364168</guid><author>iteye_15264</author><pubDate>Tue, 03 Jul 2012 08:15:31 +0800</pubDate><description><![CDATA[ 
译者注：上个月写了一遍博文，介绍一种高效的Java缓存实现http://maoyidao.iteye.com/blog/1559420。其本质是模仿Memcached的Slab，通过分配连续定长的byte[]减少大规模使用Java Heap作为缓存时不可避免的GC问题。虽然当时构思和实现这一思路时并没有参照其他开源产品，但这一思路在很多著名的开源产品上也有类似的实现。随着内存使用成本越来越低...]]></description><category></category></item><item><title><![CDATA[构建高性能服务（二）java高并发锁的3种实现]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82357650</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82357650</guid><author>iteye_15264</author><pubDate>Mon, 18 Jun 2012 22:27:58 +0800</pubDate><description><![CDATA[提高系统并发吞吐能力是构建高性能服务的重点和难点。通常review代码时看到synchronized是我都会想一想，这个地方可不可以优化。使用synchronized使得并发的线程变成顺序执行，对系统并发吞吐能力有极大影响，我的博文 http://maoyidao.iteye.com/blog/1149015 介绍了可以从理论上估算系统并发处理能力的方法。
 
那么对于必须使用synchron...]]></description><category></category></item><item><title><![CDATA[构建高性能服务（一）ConcurrentSkipListMap和链表构建高性能Java Memcached]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82341755</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82341755</guid><author>iteye_15264</author><pubDate>Tue, 12 Jun 2012 22:01:04 +0800</pubDate><description><![CDATA[ 
场景
缓存服务器是互联网后端服务中常用的基础设施。
场景（一）图片服务器上存储了大量图片，为了提高图片服务的吞吐量，希望把热门的图片加载到内存中。
场景（二）分布式存储服务，为提高访问吞吐，把大量的meta信息存储在内存中。
问题
但是使用Java语言开发缓存服务，不可避免的遇到GC问题。无论使用ehcache是基于Map实现的缓存，都会产生大量Minor GC无法回收的对象，最终...]]></description><category></category></item><item><title><![CDATA[移动互联网跨终端推送架构设想]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82340990</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82340990</guid><author>iteye_15264</author><pubDate>Mon, 11 Jun 2012 00:42:20 +0800</pubDate><description><![CDATA[1 为什么需要全平台推送？
设想你有一个很棒的应用。以电商为例，用户搜索了一些产品，后来又放入了购物车。你的服务器记录了用户的这些行为，发现他可能会对某类商品感兴趣。而这类商品又刚刚新添加了一些特别炫的新货，不需要用户再次查询，应用会立刻通知给用户：“嘿，瞧瞧这新东西，也许你会喜欢！”。从技术角度怎么实现呢？显然我们需要一个push服务。相对Pull的方式，Push不仅仅能更实时的提供信息，更省...]]></description><category></category></item><item><title><![CDATA[柔性可用和PaaS名词解释]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82339463</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82339463</guid><author>iteye_15264</author><pubDate>Wed, 06 Jun 2012 15:16:28 +0800</pubDate><description><![CDATA[某厨师出身的美食家说：“苏帮菜”的命根就是甜。这就是美食家和厨子的差别。哪个“苏帮菜”厨子不知道做“苏帮菜”要放糖呢？但是如果上升到上面这句话的高度，就可以是美食家了。
 
从码农上升到架构或者是技术主管以致部门主管也是一样，你会越来越多的和产品，和老板，和非技术的人打交道。怎么样把技术术语解释的大家都听得懂，怎么样把技术方案的优势和收益用非技术的方式表述出来，是非常重要的能力。
 
这就...]]></description><category></category></item><item><title><![CDATA[大型网站架构实现伸缩性的最佳实践]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82335556</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82335556</guid><author>iteye_15264</author><pubDate>Sat, 26 May 2012 21:56:28 +0800</pubDate><description><![CDATA[前言
为防止成为标题党，首先定义一下什么是大型网站，
（1）业务依赖多，一个业务流程，需要调用多种资源，Memcached/DB/其他模块等等；
（2）业务快速增长且不平均，比如电商网站中某一类产品增长特别明显；
（3）并发访问量高，数据量大，请求响应时间要求严格；
（4）业务要求7*24小时高可用性；
（5）业务模块多，研发团队多，业务部门多；
 
以上条件满足一部分就可以称为大...]]></description><category></category></item><item><title><![CDATA[排查Java线上服务故障的方法和实例分析]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82306414</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82306414</guid><author>iteye_15264</author><pubDate>Sun, 08 Apr 2012 22:20:57 +0800</pubDate><description><![CDATA[ 
前言
作为在线系统负责人或者是一个技术专家，你可能刚刚接手一个项目就需要处理紧急故障，或者被要求帮忙处理一些紧急的故障，这个时候的情景是：（1）你可能对这个业务仅仅是听说过，而不怎么真正了解；（2）你可能没有这个故障的详细信息，比如可能仅仅是有使用方反馈服务中断了10分钟；（3）你对代码细节还没有仔细研究过。
 
这个时候该怎么解决问题呢？根据以前的经验，工程师们常常倾向于直接登上服务...]]></description><category></category></item><item><title><![CDATA[使用Scribe重新构建log4j实现分布式日志中心]]></title><link>https://blog.youkuaiyun.com/iteye_15264/article/details/82299190</link><guid>https://blog.youkuaiyun.com/iteye_15264/article/details/82299190</guid><author>iteye_15264</author><pubDate>Mon, 19 Mar 2012 22:30:58 +0800</pubDate><description><![CDATA[在浏览了诸多中文Scribe+log4j的博客之后，我发现，大家都是很不要face的抄人家的文，却没有一点要引用原文的意思。估计是抄来抄去，抄的多了都想不起来是谁抄谁的了。
 
原作应该是 Alex Loddengaard 的大作，写的很清楚，而且还有代码。这里不需要画蛇添足，大家欣赏吧。
Configuring and Using Scribe for Hadoop Log Collect...]]></description><category></category></item></channel></rss>