您现在的位置：首页
--> 系统架构
当多核解决了 CPU 运算能力问题，当 64 bit 系统解决了内存不足问题，IO 问题依然让人困扰。 梦幻西游的服务器从更早的产品延续，已经跑了 10 年了。当初之求快速把项目做出来，用最简单的方法做出来，保证稳定可以用，自然遗留了无数问题。逻辑脚本中充斥随手可见的磁盘操作。 最终，当磁盘操作堆积起来，尤其是阻塞方式请求，并行的过程全部都在磁盘访问处串行起来了。固然整个系统的处理能力并没有下降。但用户的反应时间却会...
WSDL规范目前最新的版本是2.0 ，但是目前大部分还是按1.1的版本进行使用，而且1.1的内容看上去比2.0也简单些，所以我就翻译了这个版本。 作为一种《炒作过度的技术和概念》的一类，WEB Service的确是太过重量级，对于小型的应用，还是因该避免去使用xml和SOAP这些技术。但是在企业级的应用，WEB Service已经开始成为了一种常态，所以对其有一定了解或多或少都是有一些好处的。 当然，通过读规范来学习一门技术的方法，从来都不是一...
一个非常严重和困难的bug，能够成就一个饱经沧桑深受压力的有经验的专业程序员的职业生涯。经受这种考验的创伤程度，相当你受到了一次严重的身体伤害，离婚，或是家庭成为的离世。 研究人员在研究了计算机编程心理学后，得出了一个程序员们在解决一个困难的bug时的心路里程。这些不同的境界，很像为...
随机产生一个10个字节的字符串key,value与key相同，写入redis,当数据量达到1900w时，出现了如下的一些状况：刚开始测试程序全部写入db0,后来修改了测试程序，均匀写入其它数据库master上面的日志信息：
对于构建高可用的系统而言，都希望尽可能的避免故障，但通常来说故障是不可避免的，要尽可能做到的应该是在故障出现时能快速的屏蔽故障对核心功能的影响或快速修复，在这篇blog中，来分析下该如何更好的面对程序故障（这里就不讨论人工操作造成的状况），保障系统的高可用。
• 3PAR技术内幕
比较好的一篇3PAR的文章，转一下，3par的人今天过来，感觉东西设计上还是有特色，虚拟化上，架构设计适合高端用户，另 Chunklet等存储方式的变化都是他的特点。 3PAR 在 1999 年成立，几个创始人主要出自 Sun ，前身叫作 3PARdata ， 2008 年上市。要知道在存储技术领域竞争还是比较激烈的，EMC / HDS 等控制着高端存储的主要市场，3PAR 能突破技术壁垒并最后成功上市，没两把刷子那是绝对做不到的。 InSpire 硬件结构 3P...
最近发现在大数据量的 lua 环境中，GC 占据了很多的 CPU 。差不多是整个 CPU 时间的 20% 左右。希望着手改进。这样，必须先对 lua 的 gc 算法极其实现有一个详尽的理解。我之前读过 lua 的源代码，由于 lua 源码版本变迁，这个工作还需要再做一次。这次我重新阅读了 lua 5.1.4 的源代码。从今天起，做一个笔记，详细分析一下 lua 的 gc 是如何实现的。阅读代码整整花掉了我一天时间。但写出来恐怕比阅读时间更长。我会分几天写在 b...
我们知道Unix/Linux下的程序配置文件从来都是纯文本的，你可以自由地修改和查看，他们也没有什么什么XML之类的玩意（参看XML的这两篇文章：一，二），这个最重要的Unix文化（参看Unix传奇下篇）40多年来就这么沿续下来了。我很佩服Microsoft的创新能力，一会儿用INI，一会儿用注册表，一会又是用XML，这就是Windows的编程中那“强大”创新。 引入注册表所谓的原因 首先，让我们来看一下为什么微软觉得要使用注册表而不是ini文件，...
从09年第一次阅读Dynamo论文，到最近阅读Amazon S3的一篇专利，一路过来对论文的理解可以简单归结为两个字
TimeTunnel在做消息分发时有这样一个场景: A类消息需要做实时分析, 且量很大, 故它的消费者不会只是一台机器, 而是一组机器, 并要求这组中每台机器收到的消息量应该平均的, 即A消息在某个时刻有100条, 若有4台机器消费的话, 最佳的情况每台机器应收到25条. 这个场景就好比, 一个消息队列, 有多个线程并行消费, 如何保证每个消费线程获取的消息数量一样的.
在需要并行化处理数据的时候，采用消息队列通讯的方式来协作，比采用共享状态的方式要好的多。Erlang ，Go 都使用这一手段来让并行任务之间协同工作。 最近读完了 ZeroMQ 的 Guide。写的很不错。前几年一直有做类似的工作，但是自己总结的不好。而 ZeroMQ 把消息通讯方面的模式总结的很不错。 ZeroMQ 并不是一个对 socket 的封装，不能用它去实现已有的网络协议。它有自己的模式，不同于更底层的点对点通讯模式。
说说自己心目中的容量规划平台，其实就最后的展现来讲，容量规划平台不会太复杂，但实现起来其实是挺麻烦的，心目中容量规划平台的目标就以下两个。预测容量达到瓶颈的时间，并为扩容提供可参考的数据指标；根据业务指标或为业务发展形成扩容方案。具体内容请见全文。
最近了解了一个分布式文件系统――MooseFS，之前对分布式的东西知道的很少，分布式文件系统、分布式数据库都是近而远之，觉得太复杂了离我还很遥远。在各位老师的推动下我用6台机器实践了一下moosefs，moosefs的部署还是很简单的，和配置NFS很像，就是多了两种角色的机器，正是有了它们，才使得moosefs在可扩展性和稳定性上都要远好于NFS，在读写的性能方面，通过dd进行的简单测试来看，moosefs也就是写入的速度稍微好于NFS，读上...
在搜索引擎(SE)里BS一般对结果作CACHE，同时OS也会对倒排拉链作CACHE，也就是系统CACHE。这样可控性不强，可以考虑把两层CACHE都由BS控制，这样又带来一个问题，怎么分配两种CACHE的大小(之前也有这个问题，只是很难控制，所以就不管了)。实践中的做法，是不停地调整两者的比例，然后测试效果。这种方法的问题在于，单次测试代价很大，而解的空间很大，这样很难找到最优解。现在一般是默认，中间有一个最优解，然后向两边递...
曾经有一个争论，一边是站在SOAP这边的人，另一边则是其它人。 站在SOAP这边人，当他们在争论SOAP和Web Service框架的复杂度时，SOAP这边的人说，在引入那些WS-*东东之前，SOAP的确是简单的，这就是为什么SOAP的第一个字母S就是Simple。 在2000年的时候，有一个苦恼的程序员， 程序员: 不好意思，我的老板这周末去打高尔夫了，现在我不得不要搞一个SOAP的应用，但是我根本不知道什么是SOAP。SOAP专家，你能帮我吗？ SOAP专家: 当然...
云架构 是满足按需分配的服务而设计的软件架构。 云架构上构建服务流程是这样，基本的计算及基础设施只是在有需要时(例如处理一个用户请求)才分配出去，分配必要的资源上的需求(如计算服务器或存储)，执行特定的工作，然后放弃不必要的资源。 老蒋认为这个过程中提供整个计算及存储等基础设施管理，分配，回收等工作的就称为云管理平台。云...
春节前的一篇那些炒作过度的技术和概念中对敏捷和中国ThoughtWorks的微辞引发了很多争议，也惊动了中国ThoughtWorks公司给我发来了邮件想来找我当面聊聊。对于Agile的Fans们，意料之中地也对我进行了很多质疑和批评。我也回复了许多评论。不过，我的那些回复都是关于中国ThoughtWorks咨询师以及其咨询的方法的。我对Agile方法论中的具体内容评价的不是很多，所以，我想不妨讨论一下Agile方法论中的具体的实践（以前本站也讨论过结...
近3天十大热文
-
[71] Java开发岗位面试题归类汇总 -
[62] android 开发入门
-
[61] IOS安全–浅谈关于IOS加固的几种方法
-
[61] Go Reflect 性能
-
[61] 如何拿下简短的域名
-
[60] 【社会化设计】自我（self）部分――欢迎区
-
[58] Oracle MTS模式下 进程地址与会话信
-
[53] 图书馆的世界纪录
-
[45] find命令的一点注意事项
-
[45] WEB系统需要关注的一些点
赞助商广告
