Architecture

基于比较的分页机制 V.S. 页码式分页

基于比较的分页机制中,输入是一个被比较值。 页码式分页机制中,输入则是页码。 用户体验 对于数据不断增长的功能,页码式分页机制在用户体验方面有个缺点:你翻到下一页时可能会看到刚刚已经看到过的记录。 以贴吧为例,你进到第一页时,你看到的是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),决定大部分用户会下翻多少页;而页码式分页机制就没这个问题。

开发A/B测试功能的注意事项

有一些注意事项: 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)。

通过异步机制解耦主干流程和附加流程

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

“手动干预排序”的设计与实现

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

如果你的系统既有web界面,又要暴露remote api,应该怎么分层?

如果你的系统既有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 »

小技巧:从多个数据源中取出前10条记录

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

消息中间件可能重发消息,怎么办?

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

有必要搞pipeline之类的东西吗?

有必要搞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更容易,所以应对功能变更的能力也更强。