Architecture

基于比较的分页机制中，输入是一个被比较值。 页码式分页机制中，输入则是页码。 用户体验 对于数据不断增长的功能，页码式分页机制在用户体验方面有个缺点：你翻到下一页时可能会看到刚刚已经看到过的记录。 以贴吧为例，你进到第一页时，你看到的是06，05，04这三条记录；翻到第二页时，本应看到的是03、02、01。 然而在你翻页之前，另一个用户插进了记录07记录； 这时再看第二页时，系统认为此时第一页是07、06、05，于是把第二页04、03、02返回给你，而你刚刚已经看了记录04. tps越高，这种现象就越严重。 而基于比较的分页机制就没有这个问题。第一页看到06, 05, 04; 翻到第二页时，客户端 “告诉系统我要比04更小的三条记录”， 不管这时有没有新增记录07，系统收到的指令都是“比04更小的三条记录”，所以总是返回03、02、01. 性能 如果要对分页查看列表的功能进行性能优化，一个常见的策略就是对前几页进行缓存。用缓存有一个问题：缓存的key是哪些？ 对于页码式分页机制，缓存的key就是页码；要缓存前N页，只需缓存N个key对应的数据。 而对于比较式分页机制，缓存的key是什么？ 它可能是你系统中的任何值，而且随着数据的增减，这个值可能原来是页尾，马上就又不是了。 要缓存多少个key?  只能把所有值都缓存一遍。除了首页由于被比较值固定为0可以缓存之外，其他页都无法缓存。 用户足迹追踪 比较式分页机制对用户足迹追踪不利。你很难根据访问记录（如access log)，决定大部分用户会下翻多少页；而页码式分页机制就没这个问题。

有一些注意事项： 1. 用户所见的一致性： 张三始终看到的是A版本，李四始终看到的是B版本，否则用户会很疑惑，甚至感到被玩弄感情。关于一致性还要考虑一些边界情况：     a. 一个匿名用户在同一台机器上操作多次，应该看到同一个版本     b. 一个匿名用户看到A版本以后，再注册，仍然应该看到A版本 2. 系统应该有一个后门，随心所欲地在A/B间互切，以方便在测试阶段进行测试。 3. 使用框架，尽量减少对业务代码的侵入性，要终止A/B测试时，可以轻松搞定。框架应该重点解决一个问题：封装一个接口，返回当前请求应该对应的版本号，业务执行代码自己不应该做这个判断； 这个接口的实现可以是框架内置的通用逻辑，也可以由使用者根据特定业务实现。 4. 一次分桶测试结束后，应该清理这次测试在业务代码中的残留点，否则随着测试越来越多，这些残留点会使代码的可读性越来越多。 部分参考了： http://www.slideshare.net/patio11/ab-testing-framework-design-3296257

社区系统里的各种标签、徽章应该由谁创建，由谁来贴标签、颁发徽章？ 贴标签、颁发徽章当然要由运营操作人员来做。 谁来创建呢？如果这个标签仅仅用来显示，而不会扭曲任何if/else逻辑，那可以由操作人员在后台界面上完成。 否则，就应该由开发人员创建，因为代码里要用它。如果还没创建好，怎么用它？ 一般情况下，可以仅仅作为枚举类写死在代码里，连数据库表都不用建。

由于并发、程序bug或其他原因，你的统计值或多或少可能不那么准确。 如果说不准确可以勉强接受，超住值域之外就属于丢脸了。 如果你的页面上显示一个人发过的帖子数为-1 , 那就贻笑大方了。如果是0。即使不精确，也还说的过去。 所以，在持久化任何统计值之前，先把这个值正规化为值域的边界值(比如，小于0则置成0)。

你的记录一般会按某个业务字段排序，比如ID，生成时间等等。 在论坛或SNS系统中，你可能要允许手工调整记录间的排序，比如“置顶一个帖子”，“下沉某个帖子让人感觉它是一个月前发表的”等等。 在设计社区系统的数据库时，你首先要有意识地考虑下某个记录列表是否需要手工排序。如果需要，你应该使用一个专门的字段来解决这个问题。 ============================= 下面就说下这个字段（假设它叫 sort_order）相关的设计与实现： 1. 考虑到比较式分页的需求，这个字段的值要像ID一样不能重复。你可以用数据库的序列生成器生成这个字段，也可以像下面将要说的那样，根据一定的编码规则生成这个字段。 2. 如果你设计的是社区系统，那么你的记录的原始排序规则很有可能是“发表时间”；这时“手动干预排序”可能相当于“让人感觉某个帖子是另一个时间点发表的”。 因此，sort_order最好体现时间信息。我的做法是：sort_order = 记录创建时间的毫秒数 串接  3位随机数。 这样基本可以保证唯一，而且携带时间信息。你会问为什么不直接用纳秒数？因为系统生成纳秒数需要1毫秒以上的时延，对性能伤害很大。

在web2.0系统中，用户的一次写操作，可能不仅仅意味着系统里要新增一条相应的记录，系统里可能还有很多统计性的事情要做。 比如在社区系统中，一个用户发了一个帖子，系统除了生成这个帖子的记录之外，还要给用户的发贴数加1，用户使用过的tag数加1，每个tag对应的帖子数加1 。。。 可以把主流程（生成帖子记录）和附加流程（各种加1）整合在一个事务里执行，程序健壮且易理解。但也可以在完成主流程后，发一条消息出去，让消息的消费者完成这些统计操作。 这种 异步机制最明显的好处，就像很多人说的那样，可以 尽快响应用户请求，提升性能。 但更重要的好处是， 它实现了解耦，有利于各模块独立发展，并促进分工。 1. 把附加流程实现在主流程的模块里，不符合主模块的职责定位； 主模块可能要因此依赖很多附加模块的库，不利于系统的简洁，对发布也有影响。 2. 把附加流程实现在主流程的模块里，不利于主模块和附加模块的开发人员各司其责，代码也容易遗漏或出错。 由于异步消息的不可靠性，这样做也有它的副作用： 1. 消息可能会丢失，导致附加流程未能执行。 要解决这个问题，只有使用不丢消息的消息中间件：这个中间件只有在收到消费者的回执后才会删除消息。 2. 消息可能重复，导致附加流程执行两次。如果你的附加流程不是统计性质，则让消费者做好幂等性就好了； 如果是统计类操作的话，那就要另建去重措施了。如果对统计数值的准确性要求不高，可以用bloom filter简单搞定； 否则的话，需要在缓存里保存一段时间内的消息ID，收到消息后做下比对再决定要不要消费它。

如果你的系统既有web界面，又要暴露remote api，应该怎么分层？ 我的回答是： 1. 如果web操作为主，remote api是少数，那就用最常见的web-biz模式；web层不必那么薄，可以通过组装biz services实现use cases 2. 如果remote api为主，web操作为辅，则应该用web-app-biz模式，并且web层不准直调biz层。 ============================================== 这张图好理解，也比较容易接受：app层组装biz service并实现校验逻辑，对外暴露服务；web层本身很薄，主要职能是把请求转给app层，校验都不用做。 可能存在的争论是：为什么要禁止web层直调biz层？ 两层在同一个系统里（比如同一个JVM里），直调无障碍； 禁止直调的话，如果一个操作不作为remote api对外暴露，仍要在app层中加一层封装的代码供web层调用，岂不是很蛋疼？ 这些坏处确实是存在的。但是经验表明，禁止直调带来的好处更多： 1. 系统做大后，出于分工或性能考虑，可能需要把web层剥离为一个独立系统。 如果你禁止直调，分分钟可以完成剥离； 否则，几乎不可能，除非你直接把biz service暴露成remote api（非常不好的做法）。 2. web层直调省不了多少工作量。问自己这样一个问题：校验及报错在哪里做？ 非直调的话，校验做在app层，并使用标准的errorCode/errorMessage API返回错误，web层自己不必再校验； 直调的话，web层需要自己做一堆校验，工作量还是有的。 3. 直调时，web层要自己实现校验逻辑和biz service组装逻辑，直接使用domain objects, 这要求web层的开发者也要非常非常清楚业务逻辑；如果不允许直调，web层开发者只须组装request对象和渲染response对象，他可以把精力更多地放在javascript/css上，对业务逻辑只需有所了解即可；也就是说，web层的开发可以轻松外包（对于资源紧张的团队，这一点很有意义） 4. 最严重的问题在于，如果允许直调，对于某些use case，web层和app层可能会实现重复的校验逻辑和biz service组装逻辑。不要小看这些逻辑，可轻可重； 如果没有实现在单一的地方，系统很容易腐化 （违反DRY原则) ========================================== 禁止直调除了要作为开发规范让大家遵守，也应该在技术上作好防卫性设计。如果你用的是maven，可以这样： <!–web工程的pom.xml–> <dependency> <groupId>some.group</groupId> <artifactId>app</artifactId> </dependency> <dependency> <groupId>some.group</groupId> <artifactId>app-impl</artifactId> <exclusions> <exclusion> <groupId>some.group</groupId> <artifactId>biz</artifactId> …

如果你的系统既有web界面，又要暴露remote api，应该怎么分层？ Read More »

考虑这样的场景：论坛里有个页面，混合展示所有的精华贴和热门贴； 帖子按ID逆序排列，并且要有分页。 怎么写出一个符合这种要求的SQL？ 受限于你的数据库设计和性能约束，这样的SQL可能很难写。 有种办法是：先取出10条精华贴，再取出10条热门贴，然后再在内存里按ID逆序排列并去重，最后返回前10条。 这样做不需要做复杂的SQL查询，性能也能接受。不过，这种模式只适于 比较式分页(ID小于某个值的前10个帖子)，不适应于普通的页码式分页（第N页）。  考虑一下取第二页的场景，你就明白我的意思了。

消息中间件可能重发消息，怎么办？只能要求客户端保证幂等性了。 但这又增加了客户端的复杂性，人家可能不愿意。 其实解决办法很简单(也很流氓)，你自己做个客户端SDK，在这里面做好消息去重，然后让你的客户集成它就是了。

有必要搞pipeline之类的东西吗？ 把各块功能封装成独立的API，然后每个request handler分别调用不同的api组合不就行了吗？这样还免得搞框架，也不用写什么配置文件。 这种质疑不是没有道理，但最近的亲身体会表明，pipeline体系在开发效率、代码正确率上有确有一定优势。 比方说，要加一个切面功能的话，Pipeline模式中开发者要在各个request handler的xml配置中加上一行，API模式中开发者要修改各个 request handler类。 比较： 1. 在xml中加配置肯定比在各个类中加代码更快 2. 在xml中加不易出错，而在各个类代码中改相对容易出错     a. java代码在结构上不如xml文件清晰，插错地方的可能性比较高     b. 在java代码中新增API调用语句前要先收集输入，如果插入点的上下文没有直接可用的变量作为输入，则需要重构代码，引发bug隐患； 在xml中配置没有这个问题，因为pipeline体系中强制规定了输入变量应从pipeline context中获取，总是能获取到的。     c. 在java代码中调用API后要根据输出和异常决定下一步怎么走，这可能导致比较大的流程变更，而且不同的request handler需要做不同的变更，这非常容易出错； 在xml中配置没有这个问题，因为pipeline体系各valve自己已经决定了下一个出口，不需要调用者操心。 总结一下，pipeline体系中的处理结点是特殊的API，它们有高度统一的接口和更高的自恰性，组装起来比普通API更容易，所以应对功能变更的能力也更强。