Zhang Jiuan’ Notes

什么叫代码的可控性：
第一次听到代码可控性还在学校里，当时自已觉得搭一个网站很简单。当时我使j2ee一会就能搭一个很简单的看起来还不错的网站，于是我认为这些东西很简单；同样，在当初接触程序的时候，我差不多只会使用VC编点界面的东西，我觉得这些还算比较简单。但是，当有人需要我在win32编程接口的情况下写点小程序，我竟然一行也写不出来。后来，有人说现今有许多框架，他对用户封装了许多底层的实现，方便了用户，但同时也对用户隐藏了底层实现。因此这些底层的代码对用户不是可视的，所以它对用户是不具有可控性。一旦服务程序出了底层错误，那么使用者将陷出不可控制的状态。
代码的可控性就是在服务程序一旦出错的情况下可以很方便很快捷地定位出错位置，使对服务的监控和容错在一定的合理范围内。
代码可控性的优点：
就在两天前，一位朋友的网站down了，经过了两天才恢复，我看了就觉得很可惜。究其原因，为什么呢？我觉得一个重要原因就是他的代码不具有可控性。是的，界面做的挺漂亮，也显的很丰富。但这些可能就像一个纸质的老虎，只做到了中看的份儿吧。
如果对底层有了很好的了解，使用一些可控框架，这样的情况是完全可以避免的。因此，代码具有了可控性，那么系统可以把错误控制在一个可以接受的范围内。
怎样能够做到代码可控性：
首先，尽量不使用集成框架。比如vs，一旦底层出错，服务将很难控制。
第二，使用一些现程序是可以避免很多不必要的劳动，但是必须要有对这些库比较了解的技术人员，这样即减少了开发，又保证了底层服务可控。
第三，代码需要规范
第四，各个流程阶段，以文档保证接口规范。
 
thx
张久安
If you enjoyed this post, make sure you subscribe to my RSS feed!

转一篇网上文章：
提高效率，大致需要考虑四个方面：一是在计算能力方面考虑，二是在IO方面考虑，三是在数据库方面考虑，四是在网络传输速度方面考虑。
（一）.计算能力
原则：分散不同的计算任务到不同的节点中，尽量多的保存计算结果，尽量少的重复计算，特别是运行时重复计算。
1.负载均衡
负载均衡是多台同质服务的集合。分为软硬件两种方式，硬件效果较好，维护简单，可以用来应付大部分情况，就是需要一定的Money。比如F5、Radware等。至于软件方面，一般的大型应用服务器都提供，比如Weblogic的集群。
2.分布系统
分布系统是多台异质服务的集合。将服务分成不同类型的节点，每个节点提供特定的服务。比如可以将核心业务和辅助业务分开，将不同的辅助业务分开。
3.松散结构
松散结构是指不同的系统之间可以是异构的，系统间尽量少的通讯，一般仅采用简单的数据库同步或消息同步。个人觉得Web Service不太适合大型网站系统。松散结构除了能分散计算压力，也有助于提高系统稳定行和可维护性。
4.高效框架和算法
尽量少使用通用框架，比如Hibernate、Spring等，因为通用框架一般都是为了达到某种目的而牺牲了很多性能。对于核心业务逻辑以及最大消耗的业务逻辑，必须设计高效算法，算法设计的优劣区别往往即在于此。另外，为了照顾到开发效率和可维护性，在采用了页面静态化或文件缓存的前提下，可以在开发方面采用一些通用框架，以降低维护成本，这也是松散结构思想的提现。
5.页面静态化
对于不需要实时刷新的数据，尽量采用静态页面。对于需要定时刷新或不定期刷新的页面（刷新频率不能太高），可以考虑采用更新程序负责定期抓取更新静态页面。
6.避免频繁创建和销毁对象
对于Java而言（我觉得对于任何语言可能都一样），在内存中频繁创建和销毁对象，都会带来不小的开销。所以，尽可能使用少的同类对象，当然，同时需要考虑线程安全问题了。
（二）.IO方面
原则：尽量少的读取硬盘，尽量多的读取内存
硬盘的读取可能包括数据库存储、磁盘文件等。为了提高速度，可以将适当的数据放在内存中直接读取。
1.数据缓存
对于经常要重复使用的数据，必须要放在内存中缓存起来，不能每次都从磁盘读取。可以采用全局内存变量、Memory Cache等。
2.文件缓存
对于大的文件，特别是静态文件，比如图片、附件等，在需要频繁读取的情况下，必须要将这些数据读取到内存中缓存起来，在下次读取的时候直接从内存中读取，而不是每次都去读磁盘。可以采用squid来完成此任务。
（三）.数据库
现在的系统基本上都离不开数据库，所以，在一个系统中，数据库使用的优劣往往决定了系统效率的高下。
数据库优化的基本原则：提高数据计算能力，减少单表数据、提高查询命中率，增加冗余、减少单库和单表压力，优化查询语句、提高查询效率。
1.Rac模式、分布式数据库等
这些都是基于数据库本身的提高效率的方式。我也不太熟悉，只是大体知道。这些往往都能同时提高稳定性和效率。
2.分库策略
尽可能将访问频繁的不同业务数据分在不同的数据库来存放，这样能提高并发访问效率。
3.分表策略、及时备份历史数据策略
尽可能将大数据量的业务表采用某种分类标识来分成不同的表。可以考虑将历史数据和现实数据分开存放。
4.冗余策略
有两种层面的冗余，一种是对于经常需要关联查询的数据，可以在不同的业务表中冗余存储（字段冗余）；另外一种是对于不同的程序、不同的站点，将同质数据或者同类数据在不同的节点冗余存储（节点冗余）。
5.索引
索引有利于快速定位目标，对于提高查询效率有很大的作用；当然，索引也不能滥用，毕竟，多维护一个索引就会给数据库多增加一份压力。所以，结论是要适当使用索引。
6.SQL优化
为了查询出一个业务目标，也许有很多种查询方法，但是最优的只有一种。对于网站业务而言，特别是核心业务和大消耗业务而言，SQL的优化更是一个重要的事情。目前能想到的有参数化、预编译、考虑关联表的大小、考虑条件对索引的使用、考虑物理存储方式。有时间的话，我会专门写一下这个专题。
7.避免稀疏表
频繁地插入和删除一个表中的数据，会造成稀疏表，对于存储和查询而言都有额外的消耗。在设计数据库结构的时候需要考虑这一点。
8.连接池优化
频繁的创建和销毁数据库连接，效率应该比较低下。一般来说，都会使用连接池来提高效率。常见的有服务器自带的连接池、第三方提供的独立连接池（C3P0 、Proxool、Jakarta DBCP等）。
9.精心设计事务、尽量缩小事务范围
事务对数据库的消耗是不言而喻的，所以一定要尽量缩小事务范围，尽量避免长事务。
（四）.网络传输
1.网通、电信双线路
南电信、北网通是中国网络现状，两个网络间的互联是比较差的，所以，对于要兼顾全国用户的网站，网通、电信双线路是必须的，目前很多IDC都提供双路接入服务。
2.在各地多建分站点，特别是对于影响系统效率的关键资源
对于效率要求特别高的网站，可以考虑南北建站，这一点也是为了适应南电信、北网通的网络现状。更进一步说，可以考虑在更多的地方建分站，比如各个省会城市。当然，对于这种很多分站的系统，需要考虑数据库的节点分布问题，会带来额外的消耗。可以考虑各个站点有独立的数据库，然后定时同步数据；或者采用集中数据库，各个站点之间用专线连接起来。
3.系统内交互尽量在一个局域网内，或者采用专线来传输
系统内交互包括所有依赖于网络的交互，一般包括各个子系统之间的交互、系统和数据库之间的交互，数据库和数据库之间的交互等。
对于网站而已，安全肯定是一个不得不考虑的问题，这个在以后的文章中再来谈谈；还有，开发策略也是一个很重要的事情，以后再专文写一个。
 
thx
张久安
If you enjoyed this post, make sure you subscribe to my RSS feed!

1 数据库链接
    在讨论数据库链接前，我们首先思考一下数据库链接为我们做了些什么？首先，大家都知道数据链接需要调的函数是mysql_init(host, user, pwd, option_param)。因此数据库链接首先需要链接对应的soket，另外还需要为我们验证用户和密码的有效性，这是需要代价的。另外数据库链接为我们做的事远不止这些，比如字符集、链接属性等都会为我们做好，这些同样是需要代价的。所以，在使用数据库的时候尽量避免多次链接是有意义的。最后还有一点不容乎视，就是处理数据库的并发问题，如果N个处理同时对数据库进行链接，这对数据库是有一定压力的。虽说数据库可以配置最大链接数，但链接需要代价，另外没有对链接进行缓存，因此会有一批请求会被拒绝掉。
由如上讨论，我们可以看出设计一个维持数据数链的的池，是十分必要的。因此，系统的架构可能有如下变化:

这样，proxy维持N个与数据库的链接，处理上层应用的请求，就可以很好地解决以上所提出的问题了。
2 数据库分库分表
    如果服务器处理的数据量特别大，用户请求也特别多，那处多台服务器及多台数据库服务器共同对外提供服务的方案就必然的浮出水面。一个好的这种处理策略可以即便捷又快速地处理用户请求，给用户一个很好的体验。
    分库分表的策略有两方面决定：1 数据量的大小；2 服务器限制。如果服务器数量有限但数据量比较大，那么适当的分表，可以处理请求对单个表的压力。另外在查询的时候也可以减小扫表的代价。如果服务器资源充足，则可以考虑多分库的方案，这样可以每台服务器安置一个或N个库，可也有效地分散对数据库的压力。
分库分表可以有很多方案，比如HASH方案，比如取模或数学分式等，但一个重要原则就是近量使数据均匀地落在每个数据库和表上。
3 数据库查询优化
    对数据库的查询的优化也有许多方面，首先要想到的就是sql语句的优化。基本的原则就是前面的结果集越小，那么该方案越有利于效率的提高。第二点就是数据库索引的使用，可以很好使用数据库索引，可以使对数据很方便地定位结果集。但是索引不可烂用，因为索引过多了，每次更新的时候需要同时更新索用，那么更新的代价就大了。因此这里需要有一个均衡点，要好好把握。对不敏感或只读数据进行缓存，也是一个很好的方案。
4 数据主从应用
    mysql对数据主从的支持比较好，也很方便搭建，因此可以从主从方面考虑个别的应用。比如可以写操作在主库操用，个别的写操作在从库来操用。但需要注意的是，主从可能有时差，所以更新后立即查的时候，需要特别小心。
5 资源管理
    对于有些静态资源，采用特殊管理的方式也可以提高服务器的效率。比如对于gif,swf,jpg,js,css等资源根本不用到apache处理，直接使用lighttpd反回当前资源即可。资源不仅仅包含这个具休的资源，其实url的管理和服务器的处理时间同样是一种资源。
6 缓存
    对一些数据的使用缓存技术是很明智的。比如在apache + memcached + mysqld是一种很好的组合。其实很多东西可以用来缓存，比如用户登录信息等。但缓存不是所有信息都可缓存，比如对机密或实时要求较强的数据就不适合用来缓存。
7 稳定性
    后台架构做的再好，前台页面做的体验再美，没有一个稳定的服务是不可取的。记的前两天一个朋友的网站出了问题，竟然两天后才恢复，这对用户的伤害实在是太大了。
做服务的，稳定压倒一切！
 
thx
张久安
If you enjoyed this post, make sure you subscribe to my RSS feed!