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

在自然界中，很多生物面临生死考验的时候，往往会做出惊人的反应，其中最为大家熟知的当属壁虎，危难关头，与其坐以待毙，不如断尾求生，通过自残来换取活下去的希望。对于互联网项目而言，同样存在着很多生死考验，比如：访问量激增；数据库宕机等等，此时如果没有合理的降级方案，那么结局必然是死路一条。

• HBase在单Column和多Column情况下批量Put的性能对比分析

针对HBase在单column family单column qualifier和单column family多column qualifier两种场景下，分别批量Put写入时的性能对比情况，下面是结合HBase的源码来简单分析解释这一现象。

• 分布式全文检索系统SolrCloud简介

SolrCloud是Solr4.0版本开发出的具有开创意义的基于Solr和Zookeeper的分布式搜索方案，或者可以说，SolrCloud是Solr的一种部署方式。Solr可以以多种方式部署，例如单机方式，多机Master-Slaver方式，这些方式部署的Solr不具有SolrCloud的特色功能。

• 构建高可用和弹性伸缩的KV存储系统

作为常用的NoSQL存储系统之一，KV存储系统受到了开发者的关注。但常见的KV存储系统并不具备自动容灾和在线扩容功能，这给系统运营造成了不少麻烦。本文提出了一种构建高可用和自动弹性伸缩的KV存储系统的方法。

• 浏览器图片渲染优化

您是否见过当文档加载时其内容会显示不规律的移动。之所以会这样，是因为浏览器为了能够显示每一个加载的图像，而不断地重新调整页面的布局。浏览器通过下载并解析出图像的宽度和高度来决定图像的大小，然后就会在显示窗口中留出一个相应的矩形空间。然后浏览器就会调整页面的显示布局，以便把图像插入到显示当中。这同时也告诉我们，图像是独立的文件，它与源文件都分别是独立加载的。

• 每个程序员都应该知道的一些访问时延值

继续翻老文章，首先是从Jeff Dean的一篇PPT演示文稿中看到了这一页，觉得对这些数值形成概念还是挺有用的，就转过来了，经常拿出来看一下，最终能做到熟记于心，并能在理论分析和程序设计时用上。

• 分布式系统的事务处理

当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题： 1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。 2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。

• 分布式缓存的一起问题

主要出于可用性及高性能的考虑。传统的架构使用基于一致性哈希的分布式缓存，数据只存在一份副本，在出现cache节点单点故障时，虽然可以由一致性哈希算法将请求均匀落到其他节点，但由于穿透的请求较多，仍然给数据库带来较大的访问压力。为了避免对数据穿透带来的冲击，数据使用两份副本可以避免穿透的问题。同时在数据访问较大时候，也可以更好的分担流量，避免峰值单份数据跑满对系统带来的冲击。

• Web框架与太阳系

古语有云：工欲善其事，必先利其器。对于Web开发亦是如此，不过现在的Web框架实在是太多了！以PHP为例，有CakePHP、CodeIgniter、Symfony，Zend，Yii等等，到底谁是最合适的？事实上过多的选择往往会让人陷入「乱花渐欲迷人眼」的窘境，这些年我一直游走在各种PHP框架之间，却始终没有觅得属于自己的屠龙刀，于是我决定自己动手，就像歌里唱的那样：不是你亲手点燃的那就不能叫做火焰。

• 7 天打造前端性能监控系统

曾“夸下海口”说听完讲座后七天就可以打造自己的前端性能监控系统，既然说出去了也不能食言。从前一篇文章前端数据之美相信大家对前端数据有了一定的了解，下面就针对其中的性能数据及其监控进行详细阐述。

• 从输入 URL 到页面加载完成的过程中都发生了什么事情？

写这篇文章并不是为了帮大家准备面试，而是想借这道题来介绍计算机和互联网的基础知识，让读者了解它们之间是如何关联起来的。

• 跨平台移动框架iMAG开发入门

iMAG是一个非常简洁高效的移动跨平台开发框架，开发一次可以同时兼容Android和iOS平台，有点儿Web开发基础就能很快上手。当前移动端跨平台开发的框架有很多，但用iMAG还有一个好处，就是用iMAG开发出的App是原生的。iMAG采用XML + JavaScript（配置 + 脚本）的开发方式，它的原理是将符合iMAG开发规范的XML文件解释成对应的原生应用代码来执行。原生跨平台开发，iMAG App具有和Native App相同的性能和用户体验，因此相比PhoneGap、JQuery Mobile等Web开发框架iMAG适用于对性能要求较高的情况。

• 分布式消息系统尝试(rabbitmq, celery, redis)

最近在调整游戏的后台架构，之前因为需要快速出产品，所以整个代码都揉成一团，也基本没有做任何分层处理。现在服务器端的开发也开始逐渐招进来，所以打算打算换一套统一的架构，以后做新游戏只要做其中的业务逻辑即可。

• 规则引擎简介

现实生活中，规则无处不在。法律、法规和各种制度均是；对于企业级应用来说，在IT技术领域，很多地方也应用了规则，比如路由表，防火墙策略，乃至角色权限控制(RBAC)，或者Web框架中的URL匹配。不管是那种规则，都规定了一组确定的条件和此条件所产生的结果。

• 百度是如何使用hadoop的

百度作为全球最大的中文搜索引擎公司，提供基于搜索引擎的各种产品，几乎覆盖了中文网络世界中所有的搜索需求,因此，百度对海量数据处理的要求是比较高的，要在线下对数据进行分析，还要在规定的时间内处理完并反馈到平台上。百度在互联网领域的平台需求要通过性能较好的云平台进行处理了，Hadoop就是很好的选择。

• CAP 理论

CAP理论被很多人拿来作为分布式系统设计的金律，然而感觉大家对CAP这三个属性的认识却存在不少误区。从CAP的证明中可以看出来，这个理论的成立是需要很明确的对C、A、P三个概念进行界定的前提下的。在本文中笔者希望可以对论文和一些参考资料进行总结并附带一些思考。

• Dynamo和Cassandra海量存储基础

提到这两个系统，他们在核心思路上是非常类似的，但有一些细节性的东西又有所偏重，在分布式系统中也算是独树一帜了，很有代表性的一个系列，这些不一致的地方，最明显的地方就在于一致性上。可见，哪怕是从追求简单为上的工程化实现来说，各种不同的方式实现一致性也都有很大的不同，不过他们也有一些共性和一些独树一帜的概念，下面来做一下分别解说。

• Erlang公平调度的误解

Erlang公平调度是它的哲学（或者说坚持）之一，从第一个版本的beam代码的时间片分配和抢占开始，到最近版本的bif对公平性的坚持（比如R17版binary_to_term就大幅做了修改，代码复杂很多，执行效率也有下降，但是在碰到大的binary的情况下，通过Trap机制会让出执行权，排队后再回来断点续作）， nif（加入扣除时间片的接口），这些努力保证了erlang系统是个公平的系统。很多终端系统和业务会受益于这个哲学，如云计算。不管用户大小和业务的负载情况如何，系统性的公平性可以保证每个用户有机会被服务，对用户有很好的体验。

• 写Java也得了解CPU缓存

CPU，一般认为写C/C++的才需要了解，写高级语言的(Java/C#/pathon…)并不需要了解那么底层的东西。我一开始也是这么想的，但直到碰到LMAX的Disruptor，以及马丁的博文，才发现写Java的，更加不能忽视CPU。经过一段时间的阅读，希望总结一下自己的阅读后的感悟。本文主要谈谈CPU缓存对Java编程的影响，不涉及具体CPU缓存的机制和实现。

• 从Code Review 谈如何做技术

这两天，在微博上表达了一下Code Review的重要性。因为翻看了阿里内部的Review Board上的记录，从上面发现Code Review做得好的是一些比较偏技术的团队，而偏业务的技术团队基本上没有看到Code Review的记录。当然，这并不能说没有记录他们就没有做Code Review，于是，我就问了一下以前在业务团队做过的同事有没有Code Review，他告诉我不但没有Code Review，而且他认为Code Review没用，因为....