您现在的位置：首页
--> 系统架构
比较典型的存储云基础系统有Amazon公司的Dynamo系统与Google公司的Bigtable系统，这两种系统不但已经开始是商用（参见S3 服务和 Google App Engine服务），而且都公开了比较详细的实现论文（尤其dynamo系统论文格外详尽――可见Amazon公司的无私和自信）。它们各自实现架构迥异，存储特性不一，但都结构优美，技术上各有可称道的地方，可谓各有千秋，却又殊途同归。下面我们将针对它们两者存储数据的要求、体系架构、扩容、负载均衡、容错、数据存取及查询等我觉得重要的方面进行一些点到为止分析比较，以辨明良莠。
异步操作是强大的，它是许多高伸缩性架构的基石。异步操作在许多情况下是必须的，例如在客户端保持用户界面的响应能力，以及在日益兴起的云计算场景中。但是，异步编程又是十分困难的，它让这让许多程序员敬而远之。因此，越来越多的编程语言都对异步编程提供了相当程度的支持，其中的典型代表便是F#中的异步工作流以及Scala的Actor模型。不过目前的一些主流编程语言，如C#或是JavaScript，它们在设计之时并没有在异步编程上考虑太多，我们便会根据它们的语言特性，提供合适的异步编程模型及其实现。而本文介绍的便是其中一例：响应式编程(Reactive Programming)模型及响应式框架(Reactive Framework，简称Rx)。
不久前，在互联网上出现了一篇有趣的文章，讲的是对于同一个问题，不同层次的程序员编出的Phthon代码显示出了不同的风格，代码都很简单，有趣。
• 服务框架演变过程
我们的服务框架已经持续做了三年了，在厂内广泛的使用，目前部署在服务框架上的服务为2k+，每天经过服务框架的服务执行次数为120亿+，摸高到150亿+，三年的发展并非一帆风顺，由于经验的原因，还是摔了不少跤的，在这篇blog中，来给大家分享下，希望能够给要做服务框架或服务化的同学带来一些帮助，少走一些弯路，不一定要一开始就做成完整的服务框架，但至少先做好铺垫，避免在广泛使用后再来挽救。
NOSQL系统一般都会宣传一个特性，那就是性能好，然后为什么呢？关系型数据库发展了这么多年，各种优化工作已经做得很深了，NOSQL系统一般都是吸收关系型数据库的技术，然后，到底是什么因素束缚了关系型数据库的性能呢？我们从系统设计的角度看这个问题。
Key-Value系统只需要支持简单的随机读(Get)，写(Put)和删除(Del)操作。由于磁盘是顺序存储介质，因此可以往数据文件追加Key-Value记录并在内存中存放记录所在的磁盘位置，即索引信息。由于对同一个Key的更新(Put)操作以最后一个为准，内存中的索引只需要记录最新的Key-Value对位置即可，而对于删除操作，也是往数据文件追加一个删除记录。由于内存的大小有限，需要尽可能减小索引记录的大小，比如只支持64位的整数Key（其它类型的K...
OSDI 10中有一篇Facebook图片存储系统Haystack的论文，名称为”Finding a needle in Haystack: Facebook’s photo storage”。从这篇论文可以看出，数据量大的应用有时也并不复杂。 我们先给Facebook图片存储系统算一笔账。Facebook目前存储了260 billion图片，总大小为20PB，通过计算可以得出每张图片的平均大小为20PB / 260GB，约为800KB。用户每周新增图片数为1 billion (总大小为60TB)，平均每秒钟新增的图片数...
Java在运行时，可以根据声明周期大致把内存分为两部分：与JVM声明周期一致的内存，与线程生命周期一致的内存。根据Java虚拟机规范第二版，Java在运行时内存可以分为以下6个部分：PC计数器，栈，堆，方法区，运行时常量池，本地方法栈 。
分布式文件系统很多，包括GFS，HDFS，淘宝开源的TFS，Tencent用于相册存储的TFS (Tencent FS，为了便于区别，后续称为QFS)，以及Facebook Haystack。其中，TFS，QFS以及Haystack需要解决的问题以及架构都很类似，这三个文件系统称为Blob FS (Blob File System)。本文从分布式架构的角度对三种典型的文件系统进行对比。 我们先看GFS和HDFS。HDFS基本可以认为是GFS的一个简化版实现，二者因此有很多相似之处。
SQL Azure简介 SQL Azure是Azure存储平台的逻辑数据库，物理数据库仍然是SQL Server。一个物理的SQL Server被分成多个逻辑分片(partition)，每一个分片成为一个SQL Azure实例，在分布式系统中也经常被称作子表(tablet)。和大多数分布式存储系统一样，SQL Azure的数据存储三个副本，同一个时刻一个副本为Primary，提供读写服务，其它副本为Secondary，可以提供最终一致性的读服务。每一个SQL Azure实例的允许的最大数据量可以为1GB...
我主张浏览器应该原生提供中级API，这样才能自如地应对常见用例，同时还可以为不常见的用例留下扩展的空间。API的抽象程度太低，不利于广泛流传，更不容易引起开发社区的重视；API的抽象程度太高，由于限制的用例太专，人们要么能用，要么根本就用不了。目前来看，较新的API似乎有低级化的倾向，如此一来，开发人员在实际使用它们之前，往往需要有第三方来实现一些必要的抽象。我希望能够阻止这种趋势，好让常见用例实现起来更简单，以便人们能够立即使用它们，同时还可以对它们加以扩展。而中级API能够同时满足这两个条件。
继续前几天的话题。做梦幻西游服务器优化的事情。以往的代码，定期存盘的工作分两个步骤，把 VM 里的动态数据序列化，然后把序列化后的数据写盘。这两个步骤，序列化工作并没有独立在单独线程/进程里做，而是放在主线程的。IO 部分则在一个独立进程中。序列化任务是个繁琐的过程。非常耗时（相对于 MMORPG 这个需要对用户请求快速反应的环境）。当玩家同时在线人数升高时，一个简便的优化方法是把整个序列化任务分步完成，分摊到多...
• 冷热数据
这一周在考虑冷热数据的二期，分析了多个维度的数据，感觉有点乱，记录一下。我们的后端存储主要依赖于数据库(博文)，一般根据业务和功能进行分库/分表的拆分，来保持数据库实例的大小.在现实中遇到一系列的问题：1)文章信息,包括文章内容都存储在一块.所以单个数据库记录非常的大.2)理论上来说当数据库量越来越大的时候,理论上可以分库分表进行进一步分摊,但是实际上这个操作影响极大,包括程序的调整,服务的暂停.从目前我们的...
1 Map side tuning参数 1.1 MapTask运行内部原理 当map task开始运算，并产生中间数据时，其产生的中间结果并非直接就简单的写入磁盘。这中间的过程比较复杂，并且利用到了内存buffer来进行已经产生的部分结果的缓存，并在内存buffer中进行一些预排序来优化整个map的性能。如上图所示，每一个map都会对应存在一个内存buffer（MapOutputBuffer，即上图的buffer in memory），map会将已经产生的部分结果先写入到该buffer中，这个buff...
1 RPC RPC(Remote Procedure Call)――远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。 2 hadoop.ipc 2.1 Server RPC Server实现了一种抽象的RPC服务，同时提供Call队列。 O RPC Server结构 结构 功能 Server.Listener RPC Server的监听者，用来接收RPC Client的连接请求和数据，其中数据封装成Call后PUSH到Call队列。 Server.Handler RPC Server的Call处理者，和Server.Listener通...
近3天十大热文
-
[72] Java开发岗位面试题归类汇总 -
[62] android 开发入门
-
[61] IOS安全–浅谈关于IOS加固的几种方法
-
[61] Go Reflect 性能
-
[61] 如何拿下简短的域名
-
[60] 【社会化设计】自我（self）部分――欢迎区
-
[58] Oracle MTS模式下 进程地址与会话信
-
[53] 图书馆的世界纪录
-
[45] find命令的一点注意事项
-
[45] WEB系统需要关注的一些点
赞助商广告
