黑·白

在我读大学那几年，设计模式可谓火极一时，各大公司校招面试也几乎都会考设计模式，反观现在，则似乎很少有人聊设计模式的话题。是因为设计模式过时了吗？还是只是一个错误的概念？从个人这几年的开发经验来看，答案是否定的，设计模式并未过时，更不是一个错误的概念。从曾经的“红极一时”到如今的“门可罗雀”，只是说明软件开发行业以更加客观理性的态度来看待设计模式。软件开发领域的技术概念也似乎总是遵循这样的流行度变迁，最终一次又一次地证明不存在“银弹”。

正确看待设计模式的前提是明白什么是设计模式。正如本书一开始就强调的：“设计模式的本质是在已有的方案之上发现更好的方案（而不是全新发明）”，这是一种务实的态度，设计模式并非是一种高大上或者神秘的东西，而是一些常见的软件工程设计问题的最佳实践方案。

那么应该如何学习设计模式？个人认为软件开发技术的学习都应该以实践为前提，只有理解实践过程中遇到的种种问题，才能明白那些技术的本质和目的是什么，每种新技术都是因某个/某些问题而出现的，软件开发高手一般都反对新手一开始就一股脑地学习设计模式。有些新手学了点设计模式的理论后，甚至在软件开发过程中生搬硬套，结果是适得其反。因此，软件开发人员应该在积累了一定的开发经验，再系统地学习设计模式，效果往往也能事半功倍。

现在有些积累一定开发经验的软件开发人员，在谈起设计模式时，一脸鄙夷。我想这也不是一种客观务实的态度。软件开发不是简单的累积代码，在实现业务功能的同时应该仔细考虑如何控制软件的复杂度。软件的复杂度分为两个层面：业务逻辑复杂度和代码实现复杂度。对同一个业务系统，不同的软件开发人员会有不同的实现 ...

原文：Clarifications about Redis and Memcached

译者：youngsterxyf

译注：本文为Redis的作者所写

如果你了解我，就会知道我并不是那种认为竞品是一件坏事的人。实际上我喜欢用户有选择的空间，因此我很少做将Redis与其他技术做对比这类事情。

然而，为了选择正确的方案，用户必须获取正确的知识，这一点也是理所应当的。

本文的起因是读了Mike Perham写的一篇博文，你也许知道他是Sidekiq这一流行程序库的作者，Sidekiq又恰好使用Redis做后端。因此我毫不认为Mike是一个“反对”Redis的人。但在博文（你可以在 http://www.mikeperham.com/2015/09/24/storing-data-with-redis/ 找到这篇博文）中，他陈述到：要用缓存，“你可能应该选择Memcached（而不是Redis）”。这样看来，Mike确实简单地相信Redis不适合用做缓存，在文章中他是这样论述的：

• 1) Memcached专为缓存而设计
• 2) 它根本不会有磁盘I/O操作
• 3 ...

原文：Parallelism in one line

译者：youngsterxyf

在并行处理能力方面，Python的声名并不太好。不考虑关于线程和GIL（多数情况下是合理的）的标准论据，我认为Python中关于并行的真正问题并不是一个技术问题，而是教学问题。围绕Python线程和多进程的常见教程，一般都写得不错，但也令人乏味 - 激烈非凡，对日常真正有用的东西却很少涉及。

沿袭的例子

在DuckDuckGo（DDG）中搜索“Python多线程教程”，简单调查一下排在前面的结果，就会发现它们给出的都是同样基于Class + Queue的示例。

介绍threading/multiprocessing、生产者/消费者的真实示例代码：

# coding: utf-8
# Example.py
'''
标准的多线程生产者/消费者模式
'''

import time 
import threading 
import Queue 

class Consumer(threading.Thread): 
  def __init__(self ...

原文：Programming Quotes

译者：youngsterxyf

• C.A.R. Hoare, The 1980 ACM Turing Award Lecture

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there ...

原文：Fundamentals of concurrent programming

译者：youngsterxyf

本文是一篇并发编程方面的入门文章，以Go语言编写示例代码，内容涵盖：

• 运行期并发线程（goroutines）
• 基本的同步技术（管道和锁）
• Go语言中基本的并发模式
• 死锁和数据竞争
• 并行计算

在开始阅读本文之前，你应该知道如何编写简单的Go程序。如果你熟悉的是C/C++、Java或Python之类的语言，那么 Go语言之旅 能提供所有必要的背景知识。也许你还有兴趣读一读 为C++程序员准备的Go语言教程 或 为Java程序员准备的Go语言教程。

1. 运行期线程

Go允许使用go语句开启一个新的运行期线程，即 goroutine，以一个不同的、新创建的goroutine来执行一个函数。同一个程序中的所有goroutine共享同一个地址空间。

Goroutine非常轻量，除了为之分配的栈空间，其所占用的内存空间微乎其微。并且其栈空间在开始时非常小，之后随着堆存储空间的按需分配或释放而变化。内部实现上，goroutine会在多个操作系统线程上多路复用。如果一个goroutine阻塞了一个操作系统线程 ...

原文：Centralized Logging Architecture

译者：youngsterxyf

在中心化日志记录一文中，我介绍了几个工具，用于解决中心化日志记录的问题。但这些工具一般仅能解决这个问题的一部分， 这意味着需要综合使用几个工具来构建一个健壮的解决方案。

你需要解决问题的这几个主要方面：收集、传输、存储、以及分析。某些特殊的应用场景下，也许还希望具备告警的能力。

收集

应用程序以不同的方式产生日志，一些是通过syslog，其他一些是直接写到文件。考虑一个运行在linux主机上的典型web应用，在/var/log目录会有十几个甚至更多的日志文件， 如果一些应用指定日志存放在HOME目录或者其他位置，则这些目录下也是如此。

如果你正在运营一个基于web的应用，开发人员或者运维同事需要快速地访问日志数据以便对线上问题进行排错，那么就需要一个能够近乎实时监控日志文件变化的方案。 如果使用基于日志拷贝的方式 --- 文件以固定的时间间隔拷贝到一台中心服务器上，那么仅能检查与复制操作频率相同的新增日志数据。当站点已经挂掉，而你正在等待相关日志数据的复制， 那么一分钟一次的 rsync cron 任务也许还不够快。

从另外一个角度来看，如果需要分析线下日志数据，计算各种度量指标，或者其他批量的工作 ...

原文：phpmetrics of popular php projects

译者：youngsterxyf

之前我偶然发现一个名为phpmetrics的新工具，可用于计算及展示php的度量指标。我当时立马喜欢上了这个工具，并决定用它分析我认为重要的一些php项目。 我知道这个项目列表还远远不够完善，但应该仍然值得一看。我特别喜欢其中的“可维护性”报告，我发现视觉上那些红色的斑点就和丑陋的代码一样令人厌恶。

这个工具貌似还有点小bug，我会尽力尽快修复这个工具项目的这些小问题。

一些重要的说明

• 目前我还无法得到Cakephp和Typo3的分析报告，之后我会尽快调查一下这个问题。
• 我是在完整的代码库或下载的源码包上执行这个工具的，这意味着某些情况下还分析了项目的外部依赖库。之后我可能会调整，但目前不在计划之内。
• 有些项目包含很多代码库，所以我无法确保测试的都是正确的那个代码库。Joomla尤其可能这样。
• 某些项目并非非常知名，但在github上呈现关注度上升趋势。
• dm-mailer这个项目无足轻重，只是我最新的个人兴趣项目。我将它与phpmetrics一起归到Backfire一节。
• 注意：php-yaf和phalcon都是非常有意思的php框架，但多数代码是C实现的，因此没有包含进来。

说明：阅读该报告的一点小提示：

• 更多的斑点只是意味着更多的类
• 红色意味着不可维护，黄色表示可接受，绿色则表明良好、可维护的代码。

分析结果 ...

原文：Distributed systems theory for the distributed systems engineer

译者：youngsterxyf

Gwen Shapira，大腕级的解决方案架构师（SA），如今Cloudera的全职工程师，在Twitter上提的一个问题引起了我的思考。

如果是以前，我可能会回答“嗯，这里有篇FLP论文，这里有篇Paxos论文，这里还有篇拜占庭将军问题的论文...”，我会罗列一箩筐重要的材料，如果你一头扎进去，至少花费6个月的时间才能过一遍这些材料。然而我已逐渐明白推荐大量的理论性的论文通常恰恰是着手学习分布式系统理论的错误方式（除非你在做一个PhD项目）。论文通常比较深入难懂，需要认真地研习，通常还需要大量的时间投入(significant experience)来理清这些论文的重要贡献，以及在整个理论体系中的位置。要求工程师具备这样的专业水平又有多大的意义呢？

但是，很遗憾，对分布式系统理论方面的重大研究成果和思想进行概括、归纳、背景分析的‘导引’性质的优秀材料非常缺乏；特别是没有居高临下态度的材料。对这块空白区域的思考让我想到了另一个有趣的问题：

一个分布式系统工程师应该知道些什么分布式系统理论？

在这种情况下 ...