tar压缩多个文件
由 feiiiiiii 于 星期三, 02/03/2010 - 11:42 发表那么命令就是tar -zcvpf sum.tgz a.txt b.txt c.txt
p的意思是带上文件的原始属性。
用于系统备份和转移特别有用。
百万级高并发网站MySQL应用攻略
由 feiiiiiii 于 星期三, 02/03/2010 - 11:04 发表百万级高并发网站MySQL应用攻略
作者: 未知
在长时间的网站开发过程中，能作一个百万IP的网站对我来说真是一个新的挑战，由于本人的水平有限，所以一直就职于一个小公司，在这里也只是抱 着重在参与的想法。在以后我所讲述到的内容知识点上如有不适之处请大家多多批评指教。
在一开始接触PHP接触MYSQL的时候就听不少人说：“Mysql就跑跑一天几十万IP的小站还可以，要是几百万IP就不行了”，原话不记得 了，大体就是这个意思。一直也没有好的机会去验证这个说法，一是从没有接手过这么大流量的网站，二是平时工作也比较忙，懒得去管这些，反正现在用不着，抱 着这个想法把这个问题一直留到了最近，才把这个问题搞明白。
就在前几天公司旗下一网站(由于这是公司的商业内容我就不说是那个网站了，免得有兄弟说是AD)以下简称A站，这A站在年后流量猛增从一天的七 八十万猛跑到了好几百万的IP，一天下来接近一千万的Pv让整个服务器在高压下超负荷的工作着，时不时的服务就出现当机。
最首先反映出情况的是数据统计，一天下来一个数据也没有统计上，原来是mysql挂了。
本文就围绕这个问题来讲讲我们公司几个技术人员的解决方案。
nginx图片服务器的架构方案
由 feiiiiiii 于 星期二, 02/02/2010 - 16:28 发表存储问题就是硬盘容量问题，花钱买硬盘就可以了，看似简单，但着实也是最苦的问题。按目前探索来看，最好的方式是：在任何时刻遇到硬盘空间不够时，买颗硬盘插上，最多改改配置，就能立刻利用；另外，硬盘要能充分利用，不然图片存储量大再加上备份，很恐怖，最好是每颗硬盘都用上100%的空间。
访问量也是个大问题，如果服务不允许防盗链，那么访问量会引起带宽、服务器压力等问题，有钱的话直接扔CDN，没钱或者有更多的钱，就自己做吧。根据垣古不变的真理“越老的图，访问量也相对较少”这一点，分成两大部分，一边处理最新的图片，一边处理老旧的图片。最新的图片访问量大，但存储量较少；老图片访问量低，但存储量大。
大概分析完了，开始制定方案。
一、拟定一个存储目录规则：
在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成：/200810/16/a/b/abcde.jpg或者/2008 /10/16/a/b/abcde.jpg。按日期制定这个目录规则后，就可以按年月来拆机器了。
二、分机器，分硬盘
新型的大型bbs架构（squid+nginx）
由 feiiiiiii 于 星期二, 02/02/2010 - 16:17 发表1、高性能：所有的点击基本上全部由前端缓存负责，提供最快速的处理。
2、高保障度：不需考虑应用程序稳定与否、程序语言是何种、数据库是何种，都能从架构上保证稳定。
3、高可用性：对应用程序的修改达到最简化：在程序的某些地方加入清缓存的语句即可，当然还需要做页面静态化的工作和统计工作。
这个架构的特点和一些流程的说明：
1、主域名和图片域名分离
域名分离可以使流量分离，缓存策略分离等等，好处诸多。bbs初期一定要做好规划，将图片用另外的域名独立服务，即使没有足够机器，域名也要先分开。另外，图片服务器可以使用有别于主域名的另一个域名，一个好处是可以减少读取cookie对图片服务器的压力，另一个是提高安全性，避免cookie泄露。
2、使用LVS作为前端、二级代理和数据库的访问入口
校内相册发展过程及核心技术分析爆料
由 feiiiiiii 于 星期二, 02/02/2010 - 13:00 发表第一章 相册瓶颈所在
1.用户上传海量数据是一个头疼的事情，每天上千万的数量，又因为互联网的特殊性，会出现高峰期和低潮期，以每天 10，000，000张图片来计算，高的时候，每秒上传有可能会在上千张，而低的时候可忽略不计。
2.因为产品不同，往往上传一张原始的照片会需要压缩成四五张不同大小的图片。这个压缩过程相当消费cpu。
相信有同一问题的应该有：QQ空间，网易相册，新浪博客，flikr等等。
第二章 校内相册的发展和改革
第一阶段，原始社会。
在第一阶段，我们过着刀耕火种的生活，java代码上传+jmagick压缩，其结果就是，再多的服务器，也搞不定越来越多的访问量。
第二阶段，具有封建主义气息的资本主义社会。
这一阶段，我们痛定思痛啦，服务常常挂啊，怎么办？怎么办，当然是分布式处理，分 析下原因，原来挂是因为cpu太高，用户上传一图压成四图，太费劲了。干脆传到其他cpu多的机器去。
说时迟那时快，我们挽起袖子，一个分布式的上传压缩过程就出来了。。。
所使用的方法：
Oracle Exadata技术浅析
由 feiiiiiii 于 星期一, 02/01/2010 - 21:37 发表自从Oracle和HP推出Exadata之后，我就很关注这个产品，之前也写了一篇Oracle database machine介绍它。去年，Oracle和SUN合并后，推出了Oracle Exadata V2，相比较上一代产品有几个变化：第一，使用SUN的硬件；第二，宣称支持OLTP应用；第三，Oracle 11g R2提供了更多的新特性。
Exadata Smart Flash Cache
Exadata V2整体架构并没有太多改变，换用了SUN的硬件，除了采用intel最新的nehalem CPU以外，每台storage cell更是配置了384GB的flash，这也是为什么V2可以支持OLTP应用的关键。
- 要发表评论，请先登录 或 注册
- 阅读全文
- 31 次点击
- Feed: Hello DBA
- Original article
linux下防范arp攻击
由 feiiiiiii 于 星期六, 01/30/2010 - 13:02 发表arp欺骗的原理不多述，基本就是利用发 送假的arp数据包，冒充网关。一般在网上通讯的时候网关的IP和MAC的绑定是放在arp 缓存里面的，假的arp包就会刷新这个缓存，导致本该发送到网关的数据包发到了欺骗 者那里。解决的办法就是静态arp。
假设网关的IP是192.168.0.1，我们要 先得到网关的正确MAC，先ping一下网关：
ping 192.168.0.1
然后运行arp查看arp缓存中的网关MAC：
localhost~$ arpAddress HWtype HWaddress Flags Mask
Interface192.168.0.1 ether 00:12:34:56:78:9A C eth0
如何控制SQL执行计划之9i篇
由 feiiiiiii 于 星期四, 01/28/2010 - 20:07 发表对于一个高并发的OLTP系统，SQL执行计划的改变往往意味着灾难。很多因素都可能导致执行计划发生不可预期的改变，比如表结构，索引，统计信息等变化，甚至我们发生过一个小小的grant操作，导致执行计划失效，重新解析后生成了一个不正确的执行计，让整个系统Crash的案例。最近，我们对一个分区表增加分区后，导致了执行计划发生改变，故障再次重演。
如何控制SQL的执行计划就成为了一个课题，之前我曾经写过一篇关于调整SQL执行计划的文章，但是内容比较粗略。因为Oracle提供了很多手段去控制执行计划，所以我打算为每个版本都整理一个最佳实践。
我们设想一个场景，一个SQL本来应该走nested loop join，但是由于某种原因，突然变成了hash join，调整统计信息无效，数据库load不断升高，只留给你很少的时间，怎么办？最直接有效的方法是在SQL上加hints，但是需要程序发布，或者程序根本无法修改。
- 要发表评论，请先登录 或 注册
- 阅读全文
- 70 次点击
- Feed: Hello DBA
- Original article
Ubuntu Server 下开启远程连接 MySQL
由 feiiiiiii 于 星期四, 01/28/2010 - 00:36 发表http://blog.csdn.net/afeilxc/archive/2009/09/07/4528201.aspx
/usr/bin/ld: cannot find -lelf的错误解决
由 feiiiiiii 于 星期三, 01/27/2010 - 20:21 发表编译安装软件什么都好，就是寻找包的时候特别麻烦……
在centos下编译net-snmp又出问题，提示/usr/bin/ld: cannot find -lelf 。
解决办法是yum search elfutils-libelf-devel
找到对应版本的包，安装完毕，搞定。
