您现在的位置：首页
--> 系统架构
本文主要是从HBase应用程序设计与开发的角度，总结几种常用的性能优化方法。有关HBase系统配置级别的优化，这里涉及的不多，这部分可以参考：淘宝Ken Wu同学的博客。 1. 表的设计 1.1 Pre-Creating Regions 默认情况下，在创建HBase表的时候会自动创建一个region分区，当导入数据的时候，所有的HBase客户端都向这一个region写数据，直到这个region足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创建一些空的regions，这样当数据写入HBase时，会按照region分区情况，在集群内做数据的负载均衡。
其实之前就有写过关于python web开发框架选择的文章，之前最终选择了bottle，并给出了bottle开发的物理设计，详见之前的文章：回归简单，向Django说再见、bottle做web开发的物理设计，然而经过最...
• Thrift简析
RPC技术及实现简介 首先思考一下分布式系统中的 RPC (Remote Procedure Call) 问题，一个完整的 RPC 模块需要可以分为三个层次 服务层(service)：RPC 接口定义与实现 协议层(protocol)：RPC 报文格式和数据编码格式 传输层(transport)：实现底层的通信(如 socket)以及系统相关的功能(如事件循环、多线程
前言 多线程程序中，锁的使用往往成为系统性能的关键。在做地址可视化项目的时候，由于内存管理部分需要频繁的更新内存的引用计数，所以产生了使用自旋锁的想法，这篇文章我们从自旋锁的性能开始说起，由浅入深的给出了一种改进的自旋锁的实现。 这里我们 1) 讨论自旋锁对并发程序性能的影响； 2) glic中自旋锁的缺陷； 3) 随后提出了一种改进的(用户空间)自旋锁的实现，供大家在今后的程序设计中参考、使用。欢迎给出改进的自旋锁中的不足和意见。 关于锁 总体上来看，锁分为两种：休眠式锁和自旋锁。休眠式锁的原理是当当前线程不能获取到指定的锁时，它就让出CPU，加入到一个等待队列中，直到被唤醒，它才会被重新调度执行。自旋锁的原理是若当前线程不能获取到指定的锁，它不会主动让出CPU，而是会在一个紧凑循环中重复的检测锁是否已经可用，即忙等待(busy wait)。 休眠锁与自旋锁的对比 如果对临界资源的访问时
• 技术方案评审
新年开始，大部分公司都在启动大量新功能的规划及设计、技术人员同时在设计对应实现方案、架构师或者技术主管则需要一天内穿梭在多个技术讨论中，评审并达成成熟稳定的设计方案。从架构师的角度来考虑，如何衡量一个技术方案的优劣呢？一、评审点从总体上讲，技术方案是衡量一个团队的开发成熟度重要一方面。技术设计是否围绕核心需求key features？模块依赖关系、兼容性是否得到充分清晰的描述及共识；设计上不同的方案是否得到了充分考虑比较？是否有正反的激烈的碰撞还是行政上的领导说了算？另外代码实现是否正确执行设计，还是代码实现边走边看，与设计方案基本脱节？从细节上来看，在软件企业内经常有不同形式的方案review，架构师在做review时候需要要考察哪些环节？从互联网系统设计的角度，总结到以下几点。简洁及可维护性从工程角度来看，避免难懂的方案。技术方案尽量象PPT那样，越傻瓜的方案越有生命力。当然
注：一些内容不熟悉，所以没有翻译。原文地址在这里 Tumblr每个月增长30% , 一天5亿网页浏览，40K/sec , 每天3TB的数据存储在1000+的服务器上。最开始只有4名工程师来处理所有事情，当有20多个工程师的时候，才有实力出一些有趣的解决方案。 Tumblr最开始是典型的大型LAMP应用，现在的分布式服务模型使用了Scala, HBase, Redis, Kafka , Finagle等，现在在处理PHP应用的问题，开始走向面向服务的设计。 分布式系统工程师 Blank Matheny讲述Tumblr的架构 现状 每天5亿PV ~20 工程师平均每秒4W请求每天1+ TB 数据写入到Hadoop集群每天更多TB的数据写入到 MySQ
一直在特定领域的分布式系统一线摸爬滚打，曾取得一些微不足道的成绩，也犯过一些相当低级的错误。回头一看，每一个成绩和错误都是醉人的一课，让我在兴奋和懊恼的沉迷中成长。自己是个幸运儿，作为一个 freshman 就能够有机会承担许多 old guy 才能够有的职责。战战兢兢、如履薄冰的同时，在一线的实作和思考也让我获得了一些珍贵的经验，却直至今日才够胆量写出来一晒。这篇文章标题前面是“妄谈”两字，所持观点未必正确，我姑妄言之，有缘之人姑听之。若有些友好的讨论，亦我所愿也。 我做的虽然也是分布式系统，却不够胆去讨论通用分布式系统的设计原则。
引言 当前的“云计算”一词已经被神话，似乎快成了放之四海皆准的时髦真理，就好比当初言必称“希腊”一般，表面光芒四射，但实际上却无比教条、且越来越令人生厌。 作为“云计算”的一个普通开发者和是推广者，很有必要通过亲身实践，以正视听，希望能让后来者(云计算系统的开发者)少走弯路——有所为、有所不为。
看了一些关于网站架构方面的文章，基本上是大同小异。也就是说，基本的原则都是一样的，而且软件也都是开源软件。但难点在于整合和运营。整合需要一些自制的工具或者根据业务定制软件；运营需要考虑数据中心建设，业务流程设计等等，不是一个简单的软件问题。从小到大的演化是一个很有意思的故事，和人的成长类似
我们知道，为了应对不断增长的数据，我们对数据进行切分，存储在不同的数据库里，本文提到的数据库在非特定指明的情况下，均指一个逻辑数据库(是一组数据库，比如Master-Slave)，而非单一各个物理数据库。 其主要有两种方式： 垂直切分(Vertical Partition/Sharding):就是把不同格式的数据，存储到不同的数据库。
这是一篇命题作文，源于今天在微薄上的一系列讨(好吧，也可以说是吵架)。其实方案没有太多好坏，就看你信不信这样做能好一些或坏一些。那么，整理成 blog 写出，也就是供大家开拓思路了。 我理解的需求来源于网络服务提供程序的一个普遍场景：一个服务器程序可能会收到多个客户端的网络数据流，在每个数据流上实际上有多个独立的数据包，只有一个数据包接收完整了才能做进一步的处理。如果在一个网络连接上数据包并不完整，就需要暂时缓存住尚未接收完的数据包。 问题是：如何管理这些缓冲区比较简洁明了，且性能高效。 其实这个有许多解决方案，比如为每个网络连接开一个单独的固定长度的 buffer 。或是用 memory pool 等改善内存使用率以及动态内存分配释放，等等。今天在微薄上吵架也正是在于这些方案细节上，到底好与不好，性能到底如何。既然单开一篇 blog 了，我不像再谈任何有争议的细节，仅仅说说，用 R
自从上次写了“程序员技术练级攻略” 以来，就觉得似乎还有很多东西没有谈到，但当时没有继续思考了。而春节前有人问我，是做底层技术，还是做业务。这问题让我思考了很多，不由自主地回顾了一 下我这十多年的软件开发经历，并顺着整理分类了一下自己解决过的若干问题，还发散想了很多，经过了一个春节假期的发酵，产生了下面这篇文章。 前言 这篇文章必然是通过我的个人经历来写的。所以，我先说说个人经历吧。我的经历基本分成三个阶段。 第一阶段：我 刚毕业时在家乡的某银行工作，做些银行的业务系统，还搞些网络，电子邮件系统，OA什么的，因为大四的时候在老师的公司里实习，银行里的人际关系太复杂， 而且技术都包给了产商，所以在银行的每一天都觉得不能适应里面的工作环境。两年后离职，单位分的房也不要了，直接去了上海，在上海呆了两年，本来想做互联 网的，但是泡沫来了，最终去了一家做系统集成的国企公司还是继续做银行业务。这四年来
本文是对《big data glossary》第三章MapReduce的个人翻译，无版权 在传统的关系数据库世界中，所有的处理都发生在信息被载入存储之后，使用特定的查询语言处理高度结构化和优化的数据结构。而由Google引领，然后被许多其他网络公司所接纳的替代方式是：创建一个读写任意格式文件的流水线，在每个阶段以文件的方式交换中间结果，并且跨机器分布计算。通常基于MapReduce方法进行分布式工作的方法都需要一套全新的工具，我将在下面介绍。 Hadoop 最初是由Yahoo！开发的一套Google MapReduce架构的克隆系统，但随后被开源。Hadoop帮助你的代码在跨机器的集群上运行。它负责对输入的数据分块，并发送到各自对应的机器，在每个分块上运行代码，监测运行的代码，将结果发送到下一步的处理阶段或者最终存储下来，执行发生在map和reduce阶段间的排序工作并将排序后的数据发送到
我总感觉一个方法返回null值有问题。当读了Misko Hevery关于how to think about OO的博客文章后，又让我想起这个问题。 我感觉返回null值是有问题的，它大量的被使用在一个方法有不同的返回类型时。简单的用谷歌搜索一下“returning null”，你就会发现有建议把返回类型做成一个null对象。返回一个Null对象在某些情况下是合适的，但并不适合当你需要向客户端传送两种不同的东西的情形。用Misko重构的一段代码来说明这个问题。
摘要：天下武功，唯快不破，互联网竞争的利器就是快！且听贴吧LAMP解决方案如何全面支持快速迭代。关键词：LAMP，快速迭代领域：架构总概贴吧是功能性产品，唯快不破是永恒的准则，这一特点决定了快速迭代是需要解决的关键性问题。快速迭代，分解开来有如下部分：开发阶段，快速开发；测试阶段，包含了环境快速搭建、自动化测试工具；运维阶段，包含了集群管理技术、自动化运维工具；同时，这三方面的工作需要一个整体性的解决方案衔接起来。早期的贴吧，作为一个高性能社区，功能相对单一，全部采用C语言开发，系统可重用程度低，开发、测试效率低，运维方面的积累也很少。为了提高效率，开始尝试LAMP架构，经过几年的发展，贴吧已全部迁移到了LAMP。随着产品规模急剧膨胀，30+子系统，150+模块，500+机器，10亿+流量，在LAMP架构方面积累了很多经验，逐渐形成了快速迭代的一体化方案。如下图所示： 该解决方
摘要：前端开发通常需要开发多套web页面代码，从而为不同的移动终端浏览器开发不同的web页面，例如低端手机需使用wml，高端手机则支持html和javascript等。本文介绍了一种跨平台web页面自动化生成技术，该技术利用php设计了一个中间层（CC-lib），可以屏蔽底层的web展示语言的差异，程序运行时动态生成各个UI组件的wml/xhtml/html代码，从而可以有效降低前端开发人员的页面开发维护成本。关键词：浏览器兼容，跨平台，无线，web前端，自动化生成，CC-lib 技术领域：无线，web前端 一、背景在无线领域，通常要为不同的机型，使用不同的编程语言（wml/xhtml/html）编写网页，往往存在下面几个问题：（1）维护3份代码，开发效率低、维护成本高。（2）应用开发人员需要关注不同平台的语言差异，调试、自测繁琐。（3）业务展现逻辑代码和wml/xhtml/h
1摘要分类在搜索引擎中的应用非常广泛，这种分类属性可以方便在rank过程中针对不同类别实现不同的策略，来更好满足用户需求。本人接触分类时间并不长，在刚用SVM做分类的时候对一个现象一直比较困惑，看到大家将各种不同类型特征，拼接在一起，组成庞大的高维特征向量，送给SVM，得到想要的分类准确率，一直不明白这些特征中，到底是哪些特征在起作用，哪些特征组合在一起才是最佳效果，也不明白为啥这些特征就能够直接拼在一起，是否有更好的拼接方式？后来了解到核函数以及多核学习的一些思想，临时抱佛脚看了点，对上面的疑问也能够作一定解释，正好拿来和大家一起探讨探讨，也望大家多多指点。本文探讨的问题所列举的实例主要是围绕项目中的图像分类展开，涉及SVM在分类问题中的特征融合问题。扩展开来对其他类型分类问题，理论上也适用。关键词： SVM 特征融合 核函数 多核学习 2基本概念阐述 SVM：支持向量机，目前在
摘要本文列举了当前贴吧线下环境在使用过程中遇到的几个典型问题场景，针对这些问题，从如何维护环境稳定性以及如何提供更好的环境更新体验两个维度，给出了对应的解决方案。通过环境稳定性解决方案，降低了人力的投入，保证了环境的最新，减少了人为因素引入问题，通过技术的手段，保证整个过程自动化、可视化。通过更新方案，给予用户更好地更新体验，提升更新效率和速度，降低了执行机与基准环境之间的耦合性。 关键字基准环境 自动化 监控 稳定性 更新名词解释基准环境：在虚拟机上搭建的一个单机的贴吧全功能环境。该环境包含了贴吧的所有模块，所有模块相关的地址配置（ip、url）均指向本机，是测试开发环境构建的母本。执行机：指rd、qa、fe的开发或者测试机。
这个是 Perl 学习笔记的一部分内容，拆分出来。 Perl 新手到进阶到高手必备书籍 Learning Perl(Perl语言入门) perl 入门必读,就象别人讲的一周必读 perl 入门 Programming Perl(Perl语言编程) ...
• 数据倾斜总结
在做Shuffle阶段的优化过程中，遇到了数据倾斜的问题，造成了对一些情况下优化效果不明显。主要是因为在Job完成后的所得到的Counters是整个Job的总和，优化是基于这些Counters得出的平均值，而由于数据倾斜的原因造成map处理数据量的差异过大，使得这些平均值能代表的价值降低。Hive的执行是分阶段的，map处理数据量的差异取决于上一个stage的reduce输出，所以如何将数据均匀的分配到各个reduce中，就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。在查看了一些资料后，总结如下。 1数据倾斜的原因 1.1操作： 关键词 情形 后果 Join 其中一个表较小， 但是key集中 分发到某一个或几个Reduce上的数据远高于平均值 大表与大表，但是分桶的判断字段0值或空值过多 这些空值都由一个reduce处理，灰常慢 group by group by
近3天十大热文
-
[71] IOS安全–浅谈关于IOS加固的几种方法 -
[70] Twitter/微博客的学习摘要
-
[65] 如何拿下简短的域名
-
[64] android 开发入门
-
[63] Go Reflect 性能
-
[62] find命令的一点注意事项
-
[60] 流程管理与用户研究
-
[59] 图书馆的世界纪录
-
[59] 读书笔记-壹百度:百度十年千倍的29条法则
-
[58] Oracle MTS模式下 进程地址与会话信
赞助商广告
