大家好，我是主持人皮皮，欢迎大家做客第116期名人堂。58同城，一个被贴上“神奇”标签的网站，海量信息背后到底支撑的数据库是什么？当并发访问量相当密集的时候，这些数据库系统都会采取缓存策略？在2015中国数据库技术大会上，58同城高级架构师+技术委员会主席沈剑，将为大家带来“58同城数据库设计实践”的精彩演讲。本期名人堂我们提前探班，先睹为快，一起来看看大会剧透的亮点吧。

皮皮（Q1）：沈老师，您好！我目睹过您在我们架构师大会上的精彩演讲，架构师与DBA都属于IT行业金字塔尖的那一群人，那么DBA与架构师究竟有什么不同呢？对于特别想从事这两个行业的朋友，有没有什么好的建议？

沈剑（A1）：

1）相对系统架构师，数据库架构师更偏向数据库容量设计，数据库/表结构设计，分库分表设计，分库分表后业务灵活实现的设计，数据库扩展性可用性保证，数据库调优与运维等。

2）不管是系统架构师，还是数据库架构师，对于有志于从事这两个方向的朋友，我在这里有两个小建议：一是专注，在技术上持续投入时间，保持在一个技术领域内的专注度，切忌浮躁（很多技术人做几年就转管理而放弃了技术）；二是保持对业务的关注，一切抛开业务的架构设计和数据设计，都是在耍流氓。

皮皮（Q2）：能否分享下您即将在2015年中国数据库技术大会上的演讲主题？

沈剑（A2）：我 在2015数据库大会上分享主题是“58同城数据库设计实践”，内容包括以下几个方面，绝对干货，绝对贴近大伙日常工作，绝对用的上，欢迎有兴趣的同学参加。

一、58同城数据库设计常见问题及解决方案

1）数据量太大，怎么办？

2）数据可用性如何保证？

3）不同读写比的业务，数据库如何设计？

4）数据库字段如何无缝扩充？数据库导表如何无缝迁移？

二、58同城各类业务场景数据库拆库解决方案

1）用户库-单key场景如何拆库？

2）帖子库-双key场景如何拆库？

3）好友库-“关注”与“粉丝”场景如何拆库？

4）订单库-key场景如何拆库？

三、58同城拆库后出现的问题及解决方案

1）分库后，in查询如何实现？

2）分库后，非key查询如何实现？

3）分库后，夸库分页如何实现？

4）分库后，order by + offset + limit如何实现？

四、58同城数据库中间件初探

皮皮（Q3）：58同城的信息海量，数据量太大的情况下，如何保证高效的查询速度？58同城用到了什么样的数据库？

沈剑（A3）：

1）58同城，海量数据的检索，为了保证查询性能与查询速度，做了单独了搜索系统，而不是放在数据库里的，这套系统，如果有机会的话，我可以问问58龙哥，让他在2015架构师大会上来分享哈。当然，非检索的业务，做海量数据时，有一系列优化方案，读写比设计、拆库设计等，非一言能尽哟，欲知细节，大伙到时候来参加我的分享哈。

2）数据库，用作数据的固化存储，58还是mysql用的最多（部分固化用了mongodb，redis一般只做缓存用），但本次分享的经验，对于所有数据库都是适用滴。

皮皮（Q4）：我们知道，当并发访问量相当密集的时候，比如双11，12306购票，这些数据库系统都会采取缓存策略。请问58同城在数据库的缓存方面，有哪些优化？

沈剑（A4）：增加查询性能一般有几种方式：建立索引，增加读库，分库分表，增加缓存。在读多些少 的业务场景中，缓存是非常有效的，能极大增加系统读性能。58在数据库缓存使用上也不例外，在读多些少的核心业务中，例如用户信息、分类信息、帖子信息上都进行了缓存优化（58主要使用memcache和redis做缓存）。另外使用缓存要注意“数据不一致”这一点，常用的优化方案是读写串行化和缓存双淘汰机制，预知这两种方案的细节，来现场听我的分享哈。

皮皮（Q5）：除了缓存优化，海量数据存储于数据分析也是非常重要的，尤其是对58同城这样的以信息交换为主的网站而言，数据就是金矿。而我们知道，数据的存储和访问是需要成本的，因此通常也把数据分为冷数据和热数据，请你简单分析一下58同城是根据什么策略划分冷热数据的，并分别采取什么样的存储策略？

沈剑（A5）：58是一个生活信息平台，发布信息、浏览信息是它的核心业务。58业务场景有这样一个特点，信息的“时效性”比较强，例如：新发布的租房信息、职位信息、旧货信息会比较热，发布时间较长的信息相对比较冷。根据这个特点，58同城一般使用“时间”作为冷热数据划分依据，最新的热数据信息存储在缓存里以提高读取效率，较长时间的冷数据信息存放在数据库内。还是那句话，系统设计得依据业务场景来。

非常感谢沈剑为我们带来的精彩分享，也欢迎大家参加2015年4月份的中国数据库大会，届时和沈剑童鞋近距离交流。

【小游戏：回复大于10的整数，随机返回一篇好文】