当前位置:首页 > 开发教程 > mysql教程 >

Shining Ray(3)

时间:2013-04-24 23:59 来源:网络整理 作者:采集侠 收藏

这个问题最后有一个比较直观的答案。某个用户请求Facebook时,命中了第一批服务器其中的一个,这个服务器称之为负载均衡器;该机器的主要职责是选择一个Web服务器来处理该请求,不过它也进行一些其他目的的服务:防

这个问题最后有一个比较直观的答案。某个用户请求Facebook时,命中了第一批服务器其中的一个,这个服务器称之为负载均衡器;该机器的主要职责是选择一个Web服务器来处理该请求,不过它也进行一些其他目的的服务:防御拒绝服务攻击,多路复用用户连接等。这个负载均衡器拥有可以在第7层模式运行的能力,这样他可以检查用户请求的URI并根据这个信息进行路由选择决定。这个特性意味着,我们可以很容易地告诉负载均衡器哪些是“安全”页面,然后可以根据页面的名字和用户的位置决定是否要将请求发送到弗吉尼亚或者是加利福尼亚。

不过,这里还有一点问题。假设你访问editprofile.php来更改家乡信息。该页面没有被标记为安全所以他被引导到了加利福尼亚,并且进行了更改。然后你访问你的档案页面,同时由于这个页面是安全页面,所以被引导到了弗吉尼亚。然而因为前面提到的同步复制延迟,你可能不能立刻看到你刚刚做过的改动!这种体验会令用户感到非常混乱,同时会导致双重提交。我们通过在浏览器中设置一个包含(有过写入数据库操作的)当前时间cookie来绕开这个问题。负载均衡器会查看该cookie,如果它注意到20秒内你写入了些东西,将无条件地传送到加利福尼亚。过了20秒之后,我们确保数据已经同步到弗吉尼亚,这时便允许你回来访问安全页面。

回顾

从我们第一个用户在弗吉尼亚数据中心访问页面后的九个月中我们一直在运行同样架构获得了很好的效果。当然,一路上还有挫折;在头一两个月中,缓存一致性的框架非常地不稳定,逼我们在诊断和修复错误的时候每隔一段时间就要把流量从弗吉尼亚转移出去。当然,过了一段时间,我们消灭了这个问题,现在这个数据中心在Facebook的流量中占了很大的比重。

这个架构中主要的伸缩方面的挑战很明显:所有的写操作必须在同一个地方发生。更进一步我们对开发新的可以让我们在任何位置进行写操作的技术非常感兴趣。我们也在思考如何将新的数据中心做成一个灾难恢复点,以防怪兽要进攻加利福尼亚!想来帮帮我们吗?!

本条目发布于 2008年10月13日。属于 翻译、解决方案 分类,被贴了 Facebook、mysql、伸缩、架构 标签。作者是 ShiningRay ORDER BY RAND()

原文地址:

翻译:ShiningRay

译者序
之前有位朋友提到从MySQL随机取1条记录其实只要SELECT * FROM table ORDER BY RAND() LIMIT 1即可。其实这个语句有很大的性能问题,对于大表的效率是非常低下的。我们可以看一下MySQL对其的解释:


FROM money_logs

LIMIT 1

id select_type table type possible_keys key key_len ref rows Extra

1 SIMPLE table ALL NULL NULL NULL NULL 173784 Using temporary; Using filesort

这个SQL语句无法使用任何索引,还必须使用临时表和文件排序,在一个15万条记录的MyISAM表需要花大约0.3秒。已经是相当慢的了。如何优化,请往下看:

本条目发布于 2008年08月30日。属于 解决方案 分类,被贴了 mysql、sql、优化、排序、随机 标签。作者是 ShiningRay MySQL初级性能调整脚本

来源:

MySQL初级性能调整脚本

该脚本从“SHOW STATUS LIKE…”和“SHOW VARIABLES LIKE…”中提取信息来给出调整服务器变量的合理建议。他可以兼容所有MySQL 3.23以及更高版本(包括5.1)。

目前它会对以下内容做出建议:

MySQL复制从服务器延迟跟踪器 检查MySQL复制从服务器状态 MYSQL_BACKUP.sh

更多内容请看原页面:

本条目发布于 2008年04月12日。属于 介绍 分类,被贴了 mysql、性能 标签。作者是 ShiningRay MyISAM vs InnoDB

声明:此对比仅限于本人对公司的服务器情况所做的比较,并非通用和全面的比较。

随着公司业务的进一步扩展,服务器所承受的用户也越来越多,我也琢磨着怎么进一步提高数据库服务器的负载能力。我查到一些资料,InnoDB支持事务,支持行级锁,而且比MyISAM更具有伸缩性,MyISAM对于读取多写入少的数据库更好。

公司只有一台数据库服务器,是租用的万网双线机房的服务器(独享II型),配置并不好:

 
  • CPU:PD2.8G(双核)
  •  

  • 内存:1G DDRII
  •  

  • 硬盘:SATA -80G
  •  

  • 网卡:双1000M
  • 安装的CentOS 3.2——万网没有别的Linux操作系统,可能都是预先安装好,拿来就可以用。

    我安装了MySQL 5.0,用的是从MySQL网站上下载的RPM包。

    公司的数据库的操作中,更新和插入占了大部分,而一般的网页型的网站则大部分仅仅是查询,很多还可以被缓存,将公司的数据库查询的记录和我的BLOG的数据库查询的记录做个对比:

    Shining Ray

    Shining Ray

    (注:公司的服务器上使用了memcached,应用层将大部分记录缓存于此减轻数据库压力,所以在图上看不到多少Cache hit)
    这样,我武断地认为,因为公司的数据库主要是插入和更新这些操作,所以应该采用InnoDB格式才能更好地发挥效果。而事与愿违,在转换了格式之后,性能却出现了大幅度下滑,在每天的定时数据统计期间,还可能会导致数据库大量连接阻塞,查看了性能图像之后,发现是CPU大量的时间都用于I/O等待上了:

    Shining Ray

    对应的IO状态的性能图志:

    Shining Ray

    大家可以从图看上到,使用了InnoDB的几天在图中间反应为大量的磁盘写操作,于是之后我又切换回MyISAM,可见MyISAM的写操作少得多。

    为什么会导致这种情况发生呢?


    mysql教程阅读排行

    最新文章