当前位置:首页 > 服务器 > 正文

2012华东架构师大会分享

2012-11-18日参加了华东架构师大会,听完一天,总体而言,觉得有一些收获,不敢一个人掖着,想分享一下,其中谈到很多技术也许很多我也没接触过,只是经过时间洗刷后,留下的就是当时一瞬间的感觉和共鸣,收获的是一种思想,是演讲嘉宾在处理他们碰到问题时候的解决方法,
另外去参加会议前,正好碰到了一位同事的邮件系统有一些问题,就带着问题去,寻得了一些解决方法。
由于内容太多,我只能把我有印象的一些概念列举出来,见仁见智;

(1)云计算与下一代IDC的架构与运维(世纪互联首席专家,曾经微软的技术大拿):
a. 全球各大公司必争之地,而越大的IDC越容易赚钱,是因为单位用电量很低;
b. 用户使用云主要关心或者担心3点:
1)完全性(服务BUS作为中间人,只需要开通80和443端口,通过访问控制保证,或者支持其他的认证方式)
2)是否符合SOA(面向服务的体系结构)
3)是否具有互操作性,是否会被云捆绑(其中互操作性离不开xml)
c. 之后会有一种趋势,就是共有云和私有云同时存在,即mixed cloud…

(2)邮件系统架构的那些事(邮箱系统负责人刘建平 liujianping@tiemaile.com)
a. 邮件协议:寄信协议SMTP,收信协议:POP3和IMAP4,IMAP4的特点在于能够快速的浏览摘要和索引;
b. 邮件的反垃圾过程:
1)helo/ehlo主机名检查
2)smtp发信认证
3)地址合法性检查,和大小等check
4)相同IP的并发和链接频率
5)rbl,黑白名单和灰名单检查
6)相同帐号的发信频率
c. rbl原理:
查询某个地址是否属于黑名单
d. rbl劫持:
Spf: send police framework原理,是一种以IP地址认证电子邮件寄件人身份的技术,目前包括谷歌,雅虎等公司的邮件系统都开始使用该技术框架
e. 邮件存储:包括索引,文件和大附件
索引优化:算法优化,索引分类,设备提升
f. 成功投递之大批量投递:
1)合法的发监狱
2)必要的认证体系
3)合理的投递需求
4)投递信誉的培育
5)各大公司对这个阈值是不一样的,涉及到很多方面,大家懂的…
g. 大批量及时投递:
1)了解各系统的频率限制
2)发件人进行随机化
3)IP,发件人,发件域的认证频率
h. 针对hunter的邮箱问题:
1)考虑使用Vmime的C++邮件开发包
2)对于文件解析导致挂机的问题,考虑优化正则表达式,曾经有人用正则解析1G的邮件内容,依然正常…

(3)网络广告投放和监测系统架构剖析(洪倍 AdMaster CTO)
这里eric分享的很详细,我只补充几点:(我非常喜欢他的人格魅力和语言魅力,沟通能力超强,下午的困意一扫而光)
a. 在他们高端人士的眼中,很多道理是相通的,超强的举一反三的能力,于是他提到的非常多的就是数据的分级和缓冲,多级缓存解决高速问题,缓冲解决流速差
____________
| …
___________________|
| HDFS/NAS/
______________________|
| SSD/Flash memory
____________________|
| In-memory DB
|
b. 这里涉及到了各种因素,核心就是投入产出比,包括存储设备,性能,资金成本…(淘宝有专家实现了数据的140倍压缩),不同的硬件设备有不同的用处,
他们在全国各地布点,进行测试,每台测网速的终端成本就400多块;
c. 最终CTO可能更多关注的就是各种硬件的瓶颈,这些瓶颈需要时刻掌握,随时能够调出普通PC的硬件架构图,就是俗称的南桥和北桥,请问南桥为什么比北桥访问慢?
(因为南桥是SB,而北桥是NB)
jsj
(这个就是基本的硬件架构)
对他有兴趣,可以@admaster
client

(4)MySQL复制《主从复制》(阿里巴巴核心系统部技术专家)主讲人(花名:丁奇),
历史背景:在整个阿里系,存储成本非常高,而Oracle的收费更加夸张,尽管MySQL被收购,给MySQL带来一定模糊的前景,但是依然有很多公司喜欢他,最近网络非常流行的一片帖子《淘宝技术发展》(http://km.oa.com/articles/show/144719)
读完能大致了解到了整个阿里的架构体系,是一位淘宝从P1到P7的人写的,看完后相信会有不少启发;硬件的开支肯定重点考虑,于是MySQL在整个阿里是非常火,而且oracle逐步在转型到分布式或者MySQL;
相信从他的PPT可以看出大致的意思,而实际上主从备份在公司内部或者其他公司也用的非常多;
mysql
作者要解决的是什么问题?就是上图中的2->6之间的时间间隔,在现实环境,如果这个间隔超过N分钟,当主数据库down后,从库会有数据不一致的问题(主要原因是因为1和6,1是多线程写,而6是单线程进行更新,同时包括多线程的随机性问题);
1)5.6版本官方同步改进与局限:
主要思路:按库分线程;
主要策略:能并行的并行,不能并行的忽略;
存在问题:并行库;
2)作者设计的MySQL-Transfer设计思路是怎么样的呢?
a. 每张表靠主键更新,采用row_based binlog格式;
b. 每张表要有主键id,同时从库的foreign key check = off,这样防止在多线程更新中,有主键不一致的情况
c. slave_skip_errors = 1062; 1032
3)作者的这一架构不断在演化,抗住了去年双11的冲击,并在生产环境提供了备份机制,详细情况可以查看PPT;
(会后中间休息时间,一大群人围住了他进行咨询,非常有技术含量)

(5)社交和网页游戏后台服务器架构(游族,技术经理)
这里主要是sns后台:Flash客户端+PHP客户端(扩展)能支持住100W DAU
WEB游戏的后台:
server
作为技术经理如何选择:
业务(模块)分离还是耦合: 以业务为主
多线程还是单线程: 页游建议用单线程
自定义协议还是开源协议库: protobuf, msgpack,…
开发效率: Boost, ICE…

暂无评论

发表评论

您必须 [ 登录 ] 才能发表留言!