系统架构 -- IT技术博客大学习 -- 共学习共进步！

在过去几年，所在的微博技术团队在一定程度成功解决了feed架构的扩展性与性能的问题，大部分精力已经从应对峰值性能或者数据扩展中解放出来。几天前，拿着上面这张架构图问内部一些架构师，目前完成的工作及存在的主要问题是什么？

多年以来，主搜索的集群架构和排序算法相对比较单一，一定程度上制约了搜索业务的发展。本文主要介绍主搜索最新采用的索引分层技术。这种分层技术把主搜索集群架构从二维扩展到了三维。基于这种三维的新架构，主搜索可以根据不同的应用场景，选择不同的检索和排序算法，从而更好的提升主搜索的检索性能与检索效果。实践表明，这种分层技术能提升主搜索120%的检索性能和6%的搜索GMV。

• 好的API设计

最近在重构公司的一个交互中间件，在重新设计API及总体架构的时候思考了许多，那么什么样的API才算是一个设计良好的API呢？

• 无锁消息队列

近期在项目中用到了无锁队列 (lock free queue)这个东西，在项目中后台需要收集数据，待收集完整后需要落地，如果收集和落地都由一个进程来做，效果不好。无锁队列是蛮实用的一种数据结构。譬如，当一些后台的任务，写数据库，文件等，会出现较长时间的阻塞，可以交由后台进程去处理。这时候就涉及 IPC 方面的知识。当然，完全可以使用 fifo，mq 之类的系统预置的调用，但频繁的系统调用是吃不消的。

• 标准化与可复用杂谈

一次某用户在使用系统时候碰到一个问题，但不确认是系统的bug，于是问题通过各级的微博@ 消息反馈到产品与技术团队。在反馈链中，每一个同事都需要确认一下自己是否也出现这个问题，以便确认是否属实以及问题的范围（你可以理解互联网的从业人员为什么那么忙了）。当这个@ 消息最终传递到当事的工程师手里，他也需将描述的问题再测试一遍，如果不能重现，问题就变得更加复杂，工程师需要从一堆海量的日志去定位当时用户出现这种现象的原因。

• 应用层的容错与分层设计

服务器平均响应速度如果慢下来，慢慢消耗掉系统所有资源，进而导致整个系统不可用。因此在分布式系统中，除了远程服务本身需要有容错设计之外，在应用层的远程调用的环节，需要有良好的容错设计。应用层的容错设计有哪些方法？以下是微博团队使用过的一些实践。

• Nginx缓存解决方案：SRCache

前些天帮别人优化PHP程序，搞得灰头土脸，最后黔驴技穷开启了FastCGI Cache，算是勉强应付过去了吧。不过FastCGI Cache不支持分布式缓存，当服务器很多的时候，冗余的浪费将非常严重，此外还有数据一致性问题，所以它只是一个粗线条的解决方案。对此类问题而言，SRCache是一个细粒度的解决方案。其工作原理大致如下。。。

• Redis和Memcached的区别

Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。

• HQueue：基于HBase的消息队列

HQueue是一淘搜索网页抓取离线系统团队基于HBase开发的一套分布式、持久化消息队列。它利用HTable存储消息数据，借助HBase Coprocessor将原始的KeyValue数据封装成消息数据格式进行存储，并基于HBase Client API封装了HQueue Client API用于消息存取。 HQueue可以有效使用在需要存储时间序列数据、作为MapReduce Job和iStream等输入、输出供上下游共享数据等场合。

• 构建C1000K的服务器(2) – 实现百万连接的comet服务器

这是关于 C1000K 序列文章的第二篇, 在前一篇文章构建C1000K的服务器(1) – 基础中, 介绍了支持 C1000K 的 Linux 系统的内核参数调整和系统设置. 在本篇文章中, 将对一个真正的应用服务器做 C1000K 测试.

• 构建C1000K的服务器(1) – 基础

现在, 该是考虑 C1000K, 也就是百万连接的问题的时候了. 像 Twitter, weibo, Facebook 这些网站, 它们的同时在线用户有上千万, 同时又希望消息能接近实时地推送给用户, 这就需要服务器能维持和上千万用户的 TCP 网络连接, 虽然可以使用成百上千台服务器来支撑这么多用户, 但如果每台服务器能支持一百万连接(C1000K), 那么只需要十台服务器.

• Pora2应用中HBase高并发读写性能优化

高并发读写HBase的应用需要尽量保证对HBase的合理使用，不合理的使用有可能会导致某一个region server甚至整个hbase集群的性能出现问题，而hbase的性能问题又反过来使得所有应用性能下降，此时如果应用选择继续加大对hbase的并发访问，甚至有可能因此陷入一个性能继续变差的恶性循环。

• memory prefetch浅析

最近在用vtune分析程序性能瓶颈时，发现一些内存访问的地方竟然成了cpu热点。经过仔细分析，发现这些热点主要是对大数组非连续位置的访问的引起的。比较消耗cpu的原因应该是cache不命中。因为像这样局部性很差的内存访问逻辑，对cache是很不友好的。于是想到了prefetch……

• 中大型移动互联网公司技术架构选择

总结这些年经验，进行构架演进的方向选择时，大致要做到下面的目标：1，可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用，并可在公网访问)；2，天然可扩展(业务层无状态，尽可能全部放到最后)；3，自动化(内存不足了，除了报警，应该自动加点机器进去; 新的项目，基础代码应该都不用写，自动生成即可)。。。

• POST与GET的区别及RESTful

在网站开发的时候通常会对POST和GET产生混淆，让人混淆的主要原因是基本上POST能解决的问题GET都能解决，反之亦然。今天就来说说者两者的区别。

• 初探单点登录 SSO

单点登录(Single sign-on，SSO)是一种访问控制，在多个软件应用中，用户只需登录其中一个应用，就可以成功访问其他应用；同样，用户只需注销其中一个应用，就可以成功注销其他应用。

• 基于DRBD的高可用NFS解决方案分析

之前对DRBD分析比较多，但是一直没有找到该怎么用他。最近又在看NFS协议(RFC3530)。分析了NFS4对于的迁移、复制和服务端重启等场景的定义。DRBD提供块设备，其上是文件系统，而NFS在文件系统上层，二者结合可以构建一个高可用的文件共享解决方案。关于DRBD，在之前的博客中有一些分析(tag：DRBD)。

• Openstack Swift简介

Swift 最初是由 Rackspace 公司开发的高可用分布式对象存储服务，并于 2010 年贡献给 OpenStack 开源社区作为其最初的核心子项目之一，为其 Nova 子项目提供虚机镜像存储服务。Swift 构筑在比较便宜的标准硬件存储基础设施之上，无需采用 RAID（磁盘冗余阵列），通过在软件层面引入一致性散列技术和数据冗余性，牺牲一定程度的数据一致性来达到高可用性和可伸缩性，支持多租户模式、容器和对象读写操作，适合解决互联网的应用场景下非结构化数据存储问题。

• 手机应用/服务器开发的一些总结(二)

既然选择原生socket，那么有个基本的选择就是tcp/udp的问题. 这个其实还是看业务自己的选择，只是如果选择了udp的话，那么很多问题都可以不用考虑，比如粘包问题。但是udp有个限制是每次传输的数据大小不能超过64K，这个要注意。为了考虑复杂的情况，我们还是主要说tcp的实现，这篇文章先说下socket使用相关的一些库和代码吧

• 手机应用/服务器开发的一些总结(一)

经过这么久在android客户端和服务器端的开发，感觉还是积累了不少东西想要和大家分享一下，但是好想单独拎一个点出来又不太值得，所以就汇集到一起写成系列吧。