自我介绍
A：结合技术点做个自我介绍
B：...
A：简单介绍一下你的职责和工作内容
B：...
缓存
A：你们的缓存怎么设计的？
B：主要是内存缓存 A：讲一下你们的淘汰策略
B：LRU，用的guva的cache
A：如果让你设计个LRU，你怎么设计？
B：我会基于LinkedHashMap设计吧，hash表+链表的方式
A：为啥用链表呢？
B：因为这里是头插或者尾插的方式，链表的增删性能更高，只需要变动相邻节点
A：数据源变更的时候你们是怎么更新缓存数据的？
B：我们先写数据源，然后清掉缓存，我们每个服务器上都有个本地数据源，我们把数据落下来了
A：如果是多服务器共享的数据源呢，怎么同步每台机器上的内存缓存？
B：这个我想一下啊。。。
B：我想到一个比较笨的办法，可能不是最优解。
A：说说看
B：更新数据源的时候用消息队列去通知每个服务器，发布订阅的方式。
A：嗯，我们差不多也是这种方案
B：如果是这种场景的话缓存我可能会考虑重新设计了，感觉不是最优解。
A：你们的超时时间怎么做的呢？
B：就是用的guva的cache的超时，我们的缓存淘汰主要是通过LRU，我们的超时时间都设置的很长，我没研究过具体实现。
A：如果让你来设计呢，你怎么做？
B：参考redis的超时实现吧，lazy的方式，查询的时候检查是否超时，如果超时返回null,再配合一个后台线程，定时清理超时缓存。
A：嗯，我们也是lazy的方式
分库分表
A：聊一下分库分表吧，你们现在有用分库分表吗？
B：没用，我们现在的系统延迟要求很高，C端的请求都不会落到数据库，基本都是基于内存的。现有的数据库也都是to B的
A：好吧，那我给你构建一个场景：现在有个用户表，我们用uid做的sharding,但是我们想用时间字段做分页查询，你有什么方案吗？
B：我之前做游戏的时候有个类似的场景，我们的用户表根据服务器分表，但是有个需求，不同服务器的玩家可以相互加好友。我们的做法是抽取一个字段比较少的总表，查询的时候查总表添加好友。我感觉可以参考这种方案。如果不行的话就只能扫表，在内存汇总了。
A：嗯，现在差不多也都是总表的方案
A：我们分表的ID能基本保证递增，但是合并起来不保证递增...（这个问题没听太明白）
B：跳过吧，这个暂时没想出来
A：好的没关系
...
...
(后面还有些记不太清了)
A：好的，你有什么问题要问我的吗？
B：可以介绍下你们现在丛的项目和团队情况吗？
A：...
B：你们现在工作中的难点是什么？我过去的话主要负责什么？
A：现在主要的压力还是用户量不停创新高带来的压力，和系统升级迭代的需求
B：好的，差不多就这些吧
A：你看什么时间合适再过来现场面？
B: ...
