社区产品技术架构和设计思路的演变

《社区产品技术架构和设计思路的演变》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、社区产品技术架构和设计思路的演变纪鹏程jipengcheng@gmail.com我2007年~2011年百度贴吧后端模块开发和架构设计2011年~至今赶集网赶集交友瓜子社区社区产品特点用户数据、帖子数据、各种排序、各种消息等千万级以上的用户，百万级以上的日登陆写入的数据需要立即能看到以贴吧为例，每天2000万的发帖量，高峰时间500帖/秒写入量大1实时3逻辑复杂4用户基数大2速度！L1cachereference0.5nsL2cachereference7nsSend1Mbytesover1Gbpsn

2、etwork10msRead1Msequentiallyfrommemory0.25msDiskseek8~10msRead1MBsequentiallyfromdisk20~25ms基本原则减少IO读写-充分理解业务的读写比例合理用好cache-好钢要用在刀刃上逻辑和数据分离-逻辑是变化的，数据是不变化的可扩展性-系统能否通过加机器就可以解决流量增加问题机械磁盘性能性能差，一般应用都是随机写性能高，应用场景少，一般用在日志记录上顺序写随机写SSDvsDisk随机写性能强顺序写不如普通磁盘每个区域擦写

3、次数有限性价比不高适合数据量中等，且有大量随机写的应用拉链模式常用于存储逻辑数据存放在内存中，定期dump磁盘（mmap)用于实现高速、查询模式固定的应用用块链来节约空间拉链模式-案例Merge模式数据写到内存中定期和磁盘中的数据进行合并写到新的地方常用到论坛的帖子模式上，Google的LevelDB使用的就是该思想Cache无处不在的cache浏览器cache：客户端代理服务器cache：网络节点CDN,Squid：webservermodel层cache：memcached、redis磁盘cach

4、e：操作系统Cpucache：硬件多种多样的cache解决方案分布式cachevs本地cache磁盘cachevs内存cacheRedis--REmoteDIctionaryServerRedisvsMemcached持久化-aof、RDB-主从库并发度-epoll、libevent、selectLogicvsDataInnoDBvsMyISAM并发写事务聚簇索引运维合理使用聚簇索引createtableipush_logic(eidintunsignednotnull,uidintunsignedn

5、otnull,idxsmallintnotnull,...op_tintunsignednotnull,primrykey(eid))engine=InnoDB;createtableipush_logic(eidintunsignednotnull,uidintunsignednotnull,idxsmallintnotnull,...op_tintunsignednotnull,primrykey(uid,idx))engine=InnoDB;NoSQL对MySQL的冲击HadoopCassand

6、raMongoDBMongoDB大行其道schemafreeautosharding高速写对二维地理位置支持数据拆分性能考虑水平、垂直按业务数据拆分-案例MongoDB的分区Timeline问题推拉推拉方案利弊逻辑简单；浏览时不需计算，效率高；空间浪费大；关注变化时需要重做数据；没有空间浪费；关注变化时不需要重做数据；计算复杂；实时计算量大，需要充分利用缓存；推拉Twitter的数据1亿活跃用户Timeline接口2万QPS推送平均1ms，99%4ms以内每天2.5亿条新Tweets，平均3千/秒，峰

7、值1万以上每天260亿次分发，每秒1800万投递100万粉丝需要3.5秒，每秒可投递28万其他Web服务器的选择避免单点静态、动态内容分离能异步的尽量异步负载均衡考虑监控AntispamTHANKS