您现在的位置：首页
--> 系统架构
铁道部 12306 网站的设计最近颇招非议，除了成本高昂之外，设计不透明，交付产品看起来粗糙，订票流程问题多多，铺天盖地的非议就出来了。但是我们可以想象，即便是再糟糕的一个系统，也一定有大量的人员在投入探讨他们的解决方案。在 ITPUB 论坛上，看到一个业内人士的记录，可以一窥这个网站背后的一些思路。
现在市面上有太多的Drupal单点登录模块，以至于我们很容易就忽略了Drupal本身内建单点登录的事实。不需要任何模块，不需要任何设置，短短的20行settings.php中的代码就可以实现。这个办法在很多人那里可以使用，但是什么时候使用这个办法，还是有一些具体的要求，例如： - 这些共享一次登录的网站，在同一个主目录下，如： - www.colblog.net - forums.colblog.net - subsite.colblog.net - 必须使用mysql - 你的网站必须在同一个物理集群上，可以互相访问数据库。如果你的网站达到了这些要求，你马上就可以享受到简单、高效的单点登录了！可以使用这个办法单点登录的依据在于，Drupal有内建的机制可以使用表前缀，这样就可以让你的多个Drupal网站运行在一个MySQL的数据库中(，使用不同的表前缀来区分不同的网站)。
客户端和服务端的交互有推和拉两种方式：如果是客户端拉的话，通常就是Polling；如果是服务端推的话，一般就是Comet，目前比较流行的Comet实现方式是Long Polling。 注：如果不清楚相关名词含义，可以参考：Browser 與 Server 持續同步的作法介紹。 先来看看Polling，它其实就是我们平常所说的轮询，大致如下所示： 因为服务端不会主动告诉客户端它是否有新数据，所以Polling的实时性较差。虽然可以通过加快轮询频率的方式来缓解这个问题，但相应付出的代价也不小：一来会使负载居高不下，二来也会让带宽捉襟见肘。 再来说说Long Polling，如果使用传统的LAMP技术去实现的话，大致如下所示： 客户端不会频繁的轮询服务端，而是对服务端发起一个长连接，服务端通过轮询数据库来确定是否有新数据，一旦发现新数据便给客户端发出响应，这次交互便结束了。
Google Spanner简介 Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级，可以扩展到数百万的机器，数已百计的数据中心，上万亿的行。更给力的是，除了夸张的扩展性之外，他还能同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破CAP的枷锁，在三者之间完美平衡。
Transfer是一个主从多线程同步工具，直接patch在MySQL中。2011年开发完成。于去年的12.12上线，并撑住高峰期主从，保证从库无延迟，使得应用能够直接从从库上读数据。
硬件虚拟化技术通过虚拟化指令集、MMU(Memory Map Unit)以及IO来运行不加修改的操作系统。 传统的处理器通过选择不同的运行(Ring 特权)模式，来选择指令集的范围，内存的寻址方式，中断发生方式等操作。在原有的Ring特权等级的基础上，处理器的硬件虚拟化技术带来了一个新的运行模式：Guest模式[1]，来实现指令集的虚拟化。当切换到Guest模式时，处理器提供了先前完整的特权等级，让Guest操作系统可以不加修改的运行在物理的处理器上。Guest与Host模式的处理器上下文完全由硬件进行保存与切换。此时，虚拟机监视器(Virtual Machine Monitor)通过一个位于内存的数据结构(Intel称为VMCS, AMD称为VMCB)来控制Guest系统同Host系统的交互，以完成整个平台的虚拟化。
分布式理论 CAP(Eric Brewer) Web服务无法同时满足以下3个属性 Consistency(一致性)，数据一致更新，所有数据变动都是同步的 Availability(可用性)，每个操作都必须以可预期的响应结束 Partition tolerance(分区容错性)，即使出现单个组件无法可用,操作依然可以完成 在任何数据库设计中,一个Web应用至多只能同时支持上面的两个属性，不可能三者兼顾。对于分布式系统来说，分区容错是基本要求，所以必然要放弃一致性。对于大型网站来说， 分区容错和可用性的要求更高，所以一般都会选择适当放弃一致性。对应CAP理论，NoSQL追求的是AP，而传统数据库追求的是CA，这也可以解释为什么 传统数据库的扩展能力有限的原因。
• 位置同步策略
我们需要简化问题，并先解决一个比较小的问题集。把系统搭建起来，这样可以迭代测试。自己玩过一些，才好改进。所谓，快速原型，吃自己的狗粮。那么现阶段集中做不同玩家的位置同步。仅解决这一个问题。把 3d 客户端和服务器搭起来，可以真正的跑起来。我们的 IT ，Aply 同学已经在内网搭建了模拟环境，模拟各种糟糕的网络环境。测试恶劣环境下的表现，我们有比当年更逼真的工具来实现。
所谓 AOI ( Area Of Interest ) ，大致有两个用途。 一则是解决 NPC 的 AI 事件触发问题。游戏场景中有众多的 NPC ，比 PC 大致要多一个数量级。NPC 的 AI 触发条件往往是和其它 NPC 或 PC 距离接近。如果没有 AOI 模块，每个 NPC 都需要遍历场景中其它对象，判断与之距离。这个检索量是非常巨大的(复杂度 O(N*N) )。一般我们会设计一个 AOI 模块，统一处理，并优化比较次数，当两个对象距离接近时，以消息的形式通知它们。 二则用于减少向 PC 发送的同步消息数量。把离 PC 较远的物体状态变化的消息过滤掉。PC 身上可以带一个附近对象列表，由 AOI 消息来增减这个列表的内容。 在服务器上，我们一般推荐把 AOI 模块做成一个独立服务 。
由于公司业务需要用C做一些实现，和C++不同的是，C并没有太多的库和方案供选择，所以我们只好自力更生，努力重复造车轮。 做技术十来年的时间，说实话底层技术框架自己也写过不少个，不管是个人业余作品，还是公司业务需要的，又或者是参加开源项目所实现的，底层技术框架面临着设计、解决、实现各个方面的问题。这次MooC的设计希望能够首先满足业务的诉求，同时解决技术拓展方面和技术实施方面的问题。
经过一个月， 我基本完成了 skynet 的 C 版本的编写。中间又反复重构了几个模块，精简下来的代码并不多：只有六千余行 C 代码，以及一千多 Lua 代码。虽然部分代码写的比较匆促，但我觉得还是基本符合我的质量要求的。Bug 虽不可避免，但这样小篇幅的项目，应该足够清晰方便修正了吧。 花在 Github 上的这个开源项目上的实际开发实现远小于一个月。我的大部分时间花了和过去大半年的 Erlang 框架的兼容，以及移植那些不兼容代码和重写曾经用 Erlang 写的服务模块上面了。这些和我们的实际游戏相关，所以就没有开源了。况且，把多出这个几倍的相关代码堆砌出来，未必能增加这个开源项目的正面意义。感兴趣的同学会迷失在那些并不重要，且有许多接口受限于历史的糟糕设计中。 在整合完我们自己项目的老代码后，确定移植无误，我又动手修改了 skynet 的部分底层设计。
先简单介绍下Dump Plugin的由来，在搜索Dump中心服务化的项目中，我们把Dump中心的增量数据产出分为2个阶段，Loader阶段和Join阶段，Loader阶段把数据准备成Key-Values形式，Join阶段将数据取出，计算各种业务逻辑并产出最终数据。业务逻辑的计算是相当繁琐且易出错，这类事情做一遍足以，所以设计了一个接口，按照业务自身划分成一个个小块逻辑实现接口。这些个小业务逻辑模块即构成Dump的业务Plugin。这样做的好处： 1， 按业务本身划分，结构相对清晰，容易维护。 2， 架构和业务通过接口交互，重构架构将尽可能少的影响业务代码 3， 每个业务模块的耗时能准确统计出并能做针对性的优化。
• 基础设施之殇
你是否有这样的经历： 加入一个新项目，装了一天环境，精疲力竭，但是，我并没有写一行代码。在网上看到了一个自己有兴趣的开源项目，clone下来，构建一下失败，折腾半天环境都没搞定，最初的兴趣荡然无存。我要测试一个东西，但要配A，弄B，折腾C，别人问及进展，还没开始呢！作为项目的主力，每来一个新人，我都要帮他搭建开发环境，这些人咋就不能自己搞定呢？产品环境来bug了，可是，我本地根本重现不了。这群笨蛋，我都根他们说了多少遍，为什么还在用C的命名方式命名Java函数呢？这个要调试必须部署到远端的服务器上才能做。 …… 这样的例子，作为一个软件开发愤青，我还能举出很多。这些年软件做下来，我总能在各种各样的场景下遇到各种各样的问题，究其根源，无非是基础设施出了问题。与其说出问题，不如说是人们忽略了基础设施在软件开发项目中的重要性。
Service 调用注册服务和接口时只通过Broker Master节点， Master将注册的服务和接口信息同步给所有的Slave节点，而所有的Service 接口和Client 节点和Slave 都是有连接的，所以不同的Service 就实现了通过不同的Slave 完成消息转发，实现了负载均衡。而且消息转发的开销和原来单个Broker的开销完全相同。
NoSQL根据不同的数据模型，大致可以分为4类，分别是键值对存储(Key-Value Stores)，列族存储(Column Families)，文档数据库(Document Databases)以及图形数据库(Graph Databases)。四者从容量来讲，依次下降，而从复杂度来说则相反。 下面我根据最近看的一些资料，列出了目前常见的NoSQL数据库系统的一些主要特性，不一定都正确。另外，后面列了一些参考资料，偏向于PostgreSQL，个人觉得还不错。
最近我的工作都围绕 skynet 的开发展开。 因为这个项目是继承的 Erlang 老版本的设计来重新用 C 编写的。 再一些接口定义上也存在一些历史遗留问题. 我需要尽量兼容老版本, 这样才能把上层代码较容易的迁移过来。 最近的开发已经涉及具体业务流程了， 搬迁了不少老代码过来。 我不想污染放在外面的开源版本。 所以在开发机上同时维护了两个分支， 同时对应到 github 的公开仓库, 以及我们项目的开发仓库。 btw, 我想把自己的开发机上一个分支版本对应到办公室仓库的 master 分支， 遇到了许多麻烦。 应该是我对 git 的工作流不熟悉导致的。我的开发机的 master 对应着 github 上的 master , 但我大多数时间在一个叫 ejoy 的分支上开发。 这个分支对应到办公室服务器的 master 分支上。
Spider位于搜索引擎数据流的最上游，负责将互联网上的资源采集到本地，提供给后续检索使用，是搜索引擎的最主要数据来源之一。spider系统的目标就是发现并抓取互联网中一切有价值的网页，为达到这个目标，首先就是发现有价值网页的链接，当前spider有多种链接发现机制来尽量快而全的发现资源链接，本文主要描述其中一种针对特定索引页的链接补全机制，并给出对这种特定类型的索引页面的建议处理规范用于优化收录效果。
对于服务器的优化，很多人都有自己的经验和见解，但就我观察，有两点常常会被人忽视 - 环境切换 和 Cache Line同步 问题，人们往往都会习惯性地把视线集中在尽力减少内存拷贝，减少IO次数这样的问题上，不可否认它们一样重要，但一个高性能服务器需要更细致地去考察这些问题，这个问题我将分成两篇文章来写： 1）从一些我们常用的用户空间函数，到linux内核代码的跟踪，来看一个环境切换是如何产生的 2）从实际数据来看它对我们程序的影响
前阵子接触到一道关于数组内部链表(多用于内存池技术)的数据结构的题, 这种数据结构能够比普通链表在cache中更容易命中, 理由很简单, 就是因为其在地址上是连续的(=.=!), 借这个机会, 就对cpu cache进行了一个研究, 今天做一个简单的分享, 首先先来普及一下cpu cache的知识, 这里的cache是指cpu的高速缓存. 在我们程序员看来, 缓存是一个透明部件. 因此, 程序员通常无法直接干预对缓存的操作. 但是, 确实可以根据缓存的特点对程序代码实施特定优化, 从而更好地利用高速缓存.
近3天十大热文
-
[68] IOS安全–浅谈关于IOS加固的几种方法 -
[66] Twitter/微博客的学习摘要
-
[64] 如何拿下简短的域名
-
[61] android 开发入门
-
[60] find命令的一点注意事项
-
[59] Go Reflect 性能
-
[57] 流程管理与用户研究
-
[56] Oracle MTS模式下 进程地址与会话信
-
[56] 图书馆的世界纪录
-
[55] 读书笔记-壹百度:百度十年千倍的29条法则
赞助商广告
