这两天新系统已经进入了尾声,部署的事情也需要很多考虑了.
在从需求到开发过程中,现在注意应用的技术主要包括
1.wcf的接口读写分离,这个最大的一个好处就是可以实行权限的分离.在新系统中出现的问题是前期很多同事的代码没有考虑这个
问题,所以根据同事的建议,在代码中,动态为wcf来指定地址,来实现读写的分离.
wcf还有很多需要注意的地方,比如说客户端缓存值的设定,还有那种协议,都需要我们自己琢磨了.
2.从软件架构采用了asp.net mvc模式,并对controller和web实现了分离部署,这个部署的好处也是为了权限,毕竟controller的操
作权限不能放开.
3.代码的细节中,能一次访问数据库的,千万不要多次访问,就比如说如果一些复杂的数据库操作过程,如果可以用stringBuiler连
接依次执行或者放在存储过程中的,千万放在一起,并且加事物处理.一个关键的算法,分页算法,我们采用了下面的思路,个人感觉
效果一般,可以考虑优化,可以参考我转发的博客.
http://blog.csdn.net/hliq5399/article/details/6455781
4.缓存的加入,这个现在有些模块已经加入,但很多模块还没有加入,而且如果一个模块中,数据需要实时的话,缓存不一定能用.
这两天关注高并发,并参考了一些资料后,感觉需要加入的技术,以及可能对公司产生的有利影响:
1.分表技术,现在公司的业务也发展多年了,有些表数据已经达到了千万级别,未来可能会更多,这个时候分表特表重要了
计划采用的方式:
• sql server 2005以后出现的表分区
•分表:
这个基于基础表的分表处理方式大致的思想就是：一个主要表，保存了所有的基本信息，如果某个项目需要找到它所存储的表，
那么必须从这个基础表中查找出对应的表名等项目，好直接访问这个表。如果觉得这个基础表速度不够快，可以完全把整个基础
表保存在缓存或者内存中，方便有效的查询。
我们基于贴吧的情况，构建假设如下的3张表：
1. 贴吧版块表: 保存贴吧中版块的信息
2. 贴吧主题表：保存贴吧中版块中的主题信息，用于浏览
3. 贴吧回复表：保存主题的原始内容和回复内容
“贴吧版块表”包含如下字段：
版块ID board_id int(10)
版块名称 board_name char(50)
子表ID table_id smallint(5)
产生时间 created datetime
“贴吧主题表”包含如下字段：
主题ID topic_id int(10)
主题名称 topic_name char(255)
版块ID board_id int(10)
创建时间 created datetime
“贴吧回复表”的字段如下：
回复ID reply_id int(10)
回复内容 reply_text text
主题ID topic_id int(10)
版块ID board_id int(10)
创建时间 created datetime
那么上面保存了我们整个贴吧中的表结构信息，三个表对应的关系是：
版块 --> 多个主题
主题 --> 多个回复
那么就是说，表文件大小的关系是：
版块表文件 < 主题表文件 < 回复表文件
所以基本可以确定需要对主题表和回复表进行分表，已增加我们数据检索查询更改时候的速度和性能。
看了上面的表结构，会明显发现，在“版块表”中保存了一个"table_id"字段，这个字段就是用于保存一个版块对应的主题和回
复都是分表保存在什么表里的。
比如我们有一个叫做“PHP”的贴吧，board_id是1，子表ID也是1，那么这条记录就是：
board_id | board_name | table_id | created
1 | PHP | 1 | 2007-01-19 00:30:12
相应的，如果我需要提取“PHP”吧里的所有主题，那么就必须按照表里保存的table_id来组合一个存储了主题的表名称，比如我
们主题表的前缀是“topic_”，那么组合出来“PHP”吧对应的主题表应该是：“topic_1”，那么我们执行：
SELECT * FROMtopic_1 WHERE board_id = 1 ORDER BY topic_id DESC LIMIT 10
这样就能够获取这个主题下面回复列表，方便我们进行查看，如果需要查看某个主题下面的回复，我们可以继续使用版块表中保
存的“table_id”来进行查询。比如我们回复表的前缀是“reply_”，那么就可以组合出“PHP”吧的ID为1的主题的回复：
SELECT * FROMreply_1 WHERE topic_id = 1 ORDER BY reply_id DESC LIMIT 10
这里，我们能够清晰的看到，其实我们这里使用了基础表，基础表就是我们的版块表。那么相应的，肯定会说：基础表的数据量
大了以后如何保证它的速度和效率？
当然，我们就必须使得这个基础表保持最好的速度和性能，比如，可以采用MySQL的内存表来存储，或者保存在内存当中，比如
Memcache之类的内存缓存等等，可以按照实际情况来进行调整。
一般基于基础表的分表机制在SNS、交友、论坛等Web2.0网站中是个比较不错的解决方案，在这些网站中，完全可以单独使用一个
表来来保存基本标识和目标表之间的关系。使用表保存对应关系的好处是以后扩展非常方便，只需要增加一个表记录。
【优势】增加删除节点非常方便，为后期升级维护带来很大便利
【劣势】需要增加表或者对某一个表进行操作，还是无法离开数据库，会产生瓶颈
2.负载平衡:
这个首先的考虑是下面的文章给出的方案:
http://blog.csdn.net/hliq5399/article/details/7185246
而squid 做前端反向代理加缓存也是可以考虑的，不过可能有前面的第一种就够了
http://axislover.blog.163.com/blog/static/107765152009113091235777/
其他的方案,像我转载的博客里写的,不一定能实施太多,毕竟成本太重要了,镜像浮云也
http://blog.csdn.net/hliq5399/article/details/7185825
http://blog.csdn.net/hliq5399/article/details/7185810