1:对于基础知识的补充.
长期进行应用开发,培养的是解决问题的能力,增长的是经验,带来最大的困惑就是对技术的理解越来越浮躁,或者自欺欺人的自我安慰,认为技术仅仅是辅助工具,仅仅是一种表现形式.自我提升感觉越来越慢,感觉前面有无形的墙,还难进行升华.应该去看下数据结构等一些理论数据,也许并不能立刻提升自己,但从长期看是有益的.
摘抄一句话:
现在的程序员总是用着别人封装好的函数、类、库、API，满满的，我们就会觉得编程不过是这么回事，搭积木而已，别人都把材料提供好了，至于材料是怎么做的，不用理会。 真的是这样吗？说数据结构和算法没用的人，那是因为他用不到。为什么用不到？他的层次决定了他不会接触到编程最关键最核心的部分——算法。

2:通过技术为产品更好的服务
(1)任务不仅仅是开发,更应该严谨，通过数据去进行表达,而不应该凭经验主义去想象.
(2)通过数据积累，提供智能化的数据平台,为开发及产品提供决策.

3:挖掘及学习其他的成熟产品
通过定期的分析，去了解为什么如此做,目的是什么。将来的方向肯定是智能化,聚合化.
只要了解别人是怎么做的,才能更好的提升自己

4:开发模式
高内聚，低耦合,提供管道式的服务模式.

Twitter,Rails,Scalibility...More:
http://www.infoq.com/cn/news/2007/04/twitter-controversy
http://thegiive.javaeye.com/blog/78713

fixing twitte
http://en.oreilly.com/velocity2009/public/schedule/detail/7479
http://timyang.net/tech/twitter-operations/

twitter的性能调优关键点:
http://www.blogjava.net/iamtin/archive/2007/10/16/scaling_twitter_the_key_points.html
http://www.slideshare.net/Blaine/scaling-twitter
http://www.slideshare.net/Georgio_1999/how-to-scale-v2

可伸缩最佳实践

1:异步
web应用为提高响应速度及解耦已经在大量使用,比如mq清除cache.

2:Swim Lanes
设计模块的时候,需要明白模块在整个系统中的重要程度,以便发现问题,快速切换.

3:缓存
cache为王,分布式cache,数据cache,页面cache,cdn等等

4:监控
系统监控,应用程序分析log,子模块之间的监控,在大型网站中,也许这是最重要的.

5:数据复制

6:拆分
在应用程序上看就是mvc,数据库的拆分可能就是读写分离等等,以及数据库的外布，做到系统之间互不影响.

7:Use Few RDBMS Features
恩,我比较赞同,不过挺喜欢数据库的触发器,因为它是根源的触发,假如是应用程序触发,可能会有遗漏(尤其是代码混乱)

8:Slow Roll
我遇到过，部分机器的代码rsync没有被同步到.

9:压力/性能测试
目前做的不够,也无特定的方法

10:容量规划
不是很了解,缺少整站设计的经验,可以看看The Art of Capacity Planning Scaling Web Resources.pdf

11:回滚
只要数据不被破坏,回滚是个好方法,设计不好的网站连想回滚都不行.

12:根源分析
经常说优化/重构,可问题的根源假如没找到,那都是折腾.

13:质量
好的开始才是王道,不要说时间不够等等,不然将来是噩梦,我现在就能体会到

这是我们运维领导对于数据库优化的基础想法，总结的特别好,这样也能让人更加清晰我们到底要去做什么，为什么要去做，赞!

收获:
1:BTree工作原理.以前一直以为key (indexa,indexb,indexc),select * from table where indexa=1 and indexc=2 也是索引起效果的.

2:根据过滤范围,(indexa,indexb,indexc)索引未必比(indexa,indexb)好,原因在于"在复合索引里，仅仅只能保存一个range类型的查询字段，并且要放到复合索引的末尾，否则，range类型查询字段后面的索引无效"

3:索引是否真正效果还是和数据的记录数和过滤数有关联,尤其是复合索引

4:索引到底排序还是过滤,根据数据量有关,例子中

EXPLAIN SELECT * FROM goods WHERE cat_id=5 AND seller_id=1 ORDER BY price DESC LIMIT 10
假如seller_id具有普遍性,则不应该使用,外部排序太多了.

比较感兴趣的是下面的分页语句
explain SELECT * FROM my_data_46 JOIN (SELECT id FROM my_data_46 WHERE `uid` = 1190363061 and status=1 order by blog_pubdate DESC LIMIT 600, 10) AS p on (p.id = my_data_46.id);

(2)我们经常讲优化,恨不得用尽所有目前通用的技术解决方案,但其实我更应该分析目前存在的问题是什么,假如连这个都没有搞明白,可能会事半功倍,所以对技术应该有平和的心态,有严谨的分析态度.

(3)经常说到服务化,动不动一个应用就搞一个域名,夸张的说一个页面要下载20个不同域名的页面和接口,属于超级滥用的问题,服务整合和分离应该是有明确的分解点的.

(4)说的最多的还是数据库的问题,是否是innodb一定不myisam强呢,即使做了测试,难道测试条件一定就是正确的吗.我现在特别怀疑别人,只相信自己(有点自大),数据库的问题直接就是iowait非常大,但是每天的写入量也不大,所以有机会自己也要好好分析目前数据库存在的问题(深入学习).

(5)这是数据库还是做了一定的优化,个人感觉还是比较有用的.
a:特定的数据库根据应用不同拆分索引,简单的说比如文章数据库,查询条件无非就是列表页和文章页,这二者的查询sql和索引是不同的,可以将对应的副库放入到不同的服务器中,充分提高索引和内存的利用率
b:字段复用原理
任何数据一般都有二个属性:是否存在属性/附加属性,比如文章的status字段代表文章是否存在,kstatus字段表示这个文章是不是含有图片,是否是加密文章.一般为了解决这个问题都是进行扩字段,这样无法做到很闲扩展,也导致索引利用不够,通过字段复用(与原理)则可以解决该问题
select * from table where status=1 and kstatus & 2 = 1

(6)apache和fastcgi的问题
目前我们的页面生产机还是经典的apache1.3,用它的原因则是apache足够稳定,但他的缺点则是长时间执行,所以一旦后端资源(数据库)响应足够慢的时候,则apache就跑不上去,而fastcgi非常的敏感,一旦有波动,则直接返回给web服务器50*的错误,对于博文这样重要的页面,假如频繁产生这样的错误,会大大降低服务质量

(7)这个是个非常好笑的问题,目前我们还是使用php这样官方已经不再维护的版本,而没有升级的原因则是我们一直没有时间来弄...很变态

(8)七层设备的使用:七层能知道应用服务器的状态(比如squid的响应/apache的响应),所以是个非常好的过滤器,我们应该充分利用.

(9)服务级别的问题:一个成熟的产品可能根据自身的应用对部属和服务都划分的比较细,但这样导致的维护成本还是比较高的,研发的老大们还是坚持那种简单的服务架构,类似于几个服务池,有新应用就往里面堆,也许在推广他们的动态池吧.

(10)阻塞问题,目前服务不稳定的原因主要是,数据库高峰时刻响应不及时,导致后端生产机(apache)的cpu负载极高,整个服务都拖垮,比如上周别人一刷张,所以在优化的同时,一定要有控制策略.找出真正的瓶颈,找到了也许其他都迎刃而解了.

(11)推和拉
我们服务有个很重要的(link的uid.css),我们可以将uid.css在用户更新的时候推到静态池,也可以采用squid这样的反向代理,进行拉的模式,更新的时候则purge squid,也许每个人都有每个人的考虑,但我觉得web应用还是要简单化,正常化,坚持拉的模式.

/*
增加$x_rank值是具有$attribute属性
*/
function set_add_attribute($x_rank, $attribute)
{
return ($x_rank | $attribute);
}

/*
取消$x_rank值是具有$attribute属性
*/
function set_del_attribute($x_rank, $attribute)
{
$_temp = ~$attribute;
return ($x_rank & $_temp);
}
}

?>

以文章表来看,一般记录有二个跨度的属性,一个表示文章存在状态(删除/回收站),一个代表扩展属性(比如是否含有图片)

select * from table where status=1 and att & DATA_WAP = 1
充分利用数据库索引,可扩展

1:控制事还是控制人
2:如何做到冷静
3:如何和其他部门人合作
4:如何坚持自己和如何说服别人
5:高调的承认错误其实并不丢人
6:不能太从技术角度去考虑问题
7:如何平衡程序的编写速度与程序的质量
8:如何寻找解决问题的方法
9:难道想要了解全局一定要写代码吗?
10:如何分配任务
11:如何调动积极性

本周主要是分配任务和思考设计存在的问题,开始阶段有点迷茫,能否控制和把握全局,是我比较担心的.
技术上来讲,需要更多学习数据库的使用/优化和前端的优化.

pdt可以从http://www.eclipse.org/pdt/downloads/下载获取,pdt有xdebug和zend debugger二中调试接口,zend debugger调试插件从http://www.zend.com/en/community/pdt下载.

安装zend debugger
1：
zend_extension_ts = d:/soft/ZendDebugger.dll
zend_debugger.allow_hosts=localhost, 127.0.0.1
zend_debugger.expose_remotely=always

2：
打开eclipse,window->preferences
a:php executables:选择php.ini,php debugger,php.exe
b:php interpreter:php4
c:php servers:Default PHP Web Server(http://localhost)

debug配置:
php debugger:zend debugger
server:Default PHP Web Server(
php executable:php

本次使用tinyint的类型存储文章的各种状态,比如tinyint可以存储8个bit,就可以存储8种数据库状态,比如
7    6    5   4    3    2   1    0
保留 保留 保 推荐 置顶 草稿 删除 正常
上面的值代表:
0:表示正常文章
2:表示删除文章
4:表示草稿箱文章
8:表示置顶文章
排列组合:
3:表示正常/删除文章
6:表示草稿/删除文章

SQL语句中提供了位操作运算符,可以查询各种组合
select * from table where status & 2 = 1 ; 表示查询删除文章
select * from table where status & 3 = 1 ; 表示查询正常及删除文章

这样设计后，应用的增加对数据库查询的影响非常小。

nginx@sina.cn

lighttpd@sina.cn

nginx@sina.cn