面试让你造飞机,上班让你拧螺丝?
- 确实,在实际工作当中,大部分的工作内容都是围绕curd。但是,有些时候,对于数据结构和算法没有深入理解的人来说,一个小问题,需要磨很久才能搞定。举个实际工作当中的例子。
- 项目中有一个同步数据的需求,同步数据的接口返回如下内容。最小的offset和最大的offset,以及需要同步的内容(这些内容需要作为其他接口的请求参数),请求参数包含偏移量offset和页数page_size。
{
"message_list": {
"media_message_outer_dto": [{
"offset": 123,
"show_id": "lwi912lka",
"time_stamp": "2018-11-12",
"type": "SHOW",
"video_id": "123",
"video_source_type": "YOUKU"
}]
},
"max_offset": 54678656,
"min_offset": 54671234
}
- 现在问题来了,第一次的请求参数中的offset肯定是设为0,请求之后拿到 min_offset 和 max_offset 的值。这个接口会返回过去一个月的更新记录,而项目需要的只是同步昨天的更新。也就是说,需要在min_offset 和 max_offset 之间找到offset的值,这个值对应昨天更新的开始。要怎么样去找到这个值呢?
- 最终简化一下问题: 现在库里边有若干数据,数据里会包含当前数据更新的时间戳,已经按照更新时间排序,这些数据存放的偏移量最小是min_offset,最大是max_offset。现在最需要取出最近更新的那一小部分数据。问从什么位置(offset)开始取效率最高?
- 最low的办法肯定就是啥也不管,从头开始取,只要是早于昨天的数据就丢弃。这种办法就不评论了。
- 可能有人会抖机灵,说请求一次之后知道max_offset了,从max_offset往回捯就行。看似巧妙,实际上逻辑行不通!假设A数据在昨天更新了两次,往回捯的话,昨天第一次的更新就会更改第二次的更新。但是,第二次更新的A才是最终需要同步的,因为它更加新。这种方法看似简便,实际上会出现数据不一致的问题!更加致命!
- 一个非常熟悉的办法就可以高效地解决这个问题。二分查找!第一次请求拿到min_offset 和 max_offset之后计算0.5 (min_offset+max_offset),请求之后判断时间戳是否晚于前天,不是则继续计算新的offset,0.5 (当前offset + max_offset),直到满足时间戳条件。
- 写代码需要时刻审视自己代码的效率,看上去简单的功能,如果执行效率比较低的话,需要及时反省,找到性能的瓶颈。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。