Database & SQL
如何应对表结构经常变化？
第一种方法，预留字段.不管怎样，预留字段的方式还是很解决很多问题的，而且基本不影响性能，除了额外的meta信息描述外，也没有其他的负担。
第二种方法，使用复杂字段.使用复杂字段的好处就在于比较灵活，同一类型的数据可以放在一起（实际上相当于把应该是一个关联表的数据放一个字段里了），操作的性能也不错，但是复杂字段里面的内容查询比较困难.
还有一种方法，将数据的存储和索引（需要查询的内容）分开存放，相当于主表就一个key-value，value就是一个大的xml（或者其他的一坨），把需要查询的字段放到其他单独的表里去，可以参考friendfeed如何使用mysql.
还有column based db，也可以很好的解决这个问题，实际上他就本本回避了加字段的问题，不过现在似乎没有性能很好的实现
公交车路线查询系统后台数据库设计–查询算法
公交车路线查询系统后台数据库设计–关联地名和站点
SOA
SOA(面向服务的开发) 简介
微软SOA平台体系架构介绍
SOA@eBay 读后感
SOA与服务识别
面向服务架构（SOA）已被作为一种通过对齐IT和业务来促进业务机动性的方法被广泛接受。这种方法的主要不同之处在于，用相对较低的成本就能轻易 地获得某种机动性。在较高的层次，该方法试图将第n次业务变更所产生的增量成本降低到零或接近于零。组织推行SOA项目目的就是为了在他们的SOA之旅当 中尽早达到这个难以捉摸的第n个迭代。在实践中，要达到这种最佳状态的时间可能得花数年，甚至更长时间。
Architecture & Design
探秘：AOP能否解决紧密耦合的难题
虽然动态横切（其中对象的运行时行为可以改变）被认为是AOP的根基之一，但静态横切却是一种远不为人所知的技术。
Scalability
大规模集群下的http 状态解决方案
Java
Java 语言中的函数编程
Jrebel原理剖析
Reloading Java Classes 401: HotSwap and JRebel — Behind the Scenes
Difference between HashMap and IdentityHashMap
Linux
关于cronExpression的介绍
其他
我在QQ邮箱的这四年（一） [转]
张小龙（Foxmail的作者）认为互联网团队中的管理不是管人，而是管理产品体验，以产品体验为核心，产品设计和开发人 员与产品共同提升，共同进步。小龙之于QQ邮箱的影响正如乔布斯之于苹果的影响。
当时(2005)的javascript代码有很重的面向对象的味道，用传统的软件工程思想构建了 整个web框架，从软件的开发流程来说，这并没有什么问题，但是产品却有很大的问题出现了–慢，不是一般的慢，当时除了较快的电信网用户可以登陆进邮箱 之外，其他的用户基本上都被卡在登陆上。06年的大部分时间，整个团队都在解决速度慢的问题，尝试了很多方法，把js容量压缩掉了一半，js混淆之后又压 缩了很多，js文件分开为多个，但始终没有根本的转变，速度的提升仍然不能被用户接受。现在回过头分析这个问题，我觉得物理上的压缩和分割js文件之所以 解决不了问题是因为问题的根本在于js的逻辑架构上，当时的js有明显的基类和继承类结构体系，这种结构并不适合物理上的分割，即使分割开，渲染消耗的时 间是节省不下来的。
Javascript
实用的JavaScript 测试及效验工具
How FriendFeed uses MySQL to store schema-less data 这篇文章发布已经有一段时间了，之前也读过没留下什么映像，最近又重读了一遍做了一些笔记，内容如下。
- 数据库查询需要得到索引的支持，索引在加速查询的同时，也会直接影响了数据插入、更新的速度。另外，由于FriendFeed的数据量比较大，维护索引而引起的相关表的锁表时间会比较长。
- FriendFeed使用了读写分离技术和memcache来提升数据读取吞吐量
- FriendFeed使用了Sharding技术来提升数据写入吞吐量
- 由于Sharding技术的使用，有些很基础的关系运算就不能被支持了，例如Join。这样Mysql退化成了一个键值(KeyValue)数据库。
- 键值数据库很多。FriendFeed没有使用专门的键值数据库可能考虑多种原因
- 存储表的物理主键是autoincremen，而逻辑上的主键使用的是uuid。之所以这样做是因为uuid的不重复性对数据分布有好处，但因为InnoDB表类型会按照主键排序，此时如果使用类似uuid这样的无序串作为主键的话，那么当插入新行的时候，新行在数据文件中的位置是不确定的，这就会带来一个沉重的IO负担，而如果采用自增字段作为主键的话就不存在这个问题，因为新行始终位于数据文件的结尾。
关于FriendFeed如何保存schema-less数据的细节，这里就不在描述了，大家可以参考How FriendFeed uses MySQL to store schema-less data 或是老王的解读FriendFeed对MySQL的使用
参考资料
How FriendFeed uses MySQL to store schema-less data 原文
解读FriendFeed对MySQL的使用
在最近阅读一些可伸缩性原则的文章中经常会有根数据库事务的ACID做比较的情况，所以特此从维基百科上摘抄了相关内容以备日后查阅。
ACID，是指在数据库管理系统（DBMS）中事务所具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。
- 原子性：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
- 一致性：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
- 隔离性：两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。
- 持久性：在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
参考资料
维基百科中关于ACID的解释
