How FriendFeed uses MySQL to store schema-less data BackgroundWe use MySQL for storing all of the data in FriendFeed. Our database has grown a lot as our user base has grown. We now store over 250 million entries and a bunch of other data, from comments and “likes” to friend lists.As our database has grown, we have tried to iteratively deal with the scaling issues that come with rapid growth. We did the typical things, like using read slaves and memcache to increase read throughput and sharding our database to improve write throughput. However, as we grew, scaling our existing features to accomodate more traffic turned out to be much less of an issue than adding new features.In particular, making schema changes or adding indexes to a database with more than 10 – 20 million rows completely locks the database for hours at a time. Removing old indexes takes just as much time, and not removing them hurts performance because the database will continue to read and write to those unused blocks on every INSERT, pushing important blocks out of memory. There are complex operational procedures you can do to circumvent these problems (like setting up the new index on a slave, and then swapping the slave and the master), but those procedures are so error prone and heavyweight, they implicitly discouraged our adding features that would require schema/index changes. Since our databases are all heavily sharded, the relational features of MySQL like JOIN have never been useful to us, so we decided to look outside of the realm of RDBMS.Lots of projects exist designed to tackle the problem storing data with flexible schemas and building new indexes on the fly (e.g., CouchDB). However, none of them seemed widely-used enough by large sites to inspire confidence. In the tests we read about and ran ourselves, none of the projects were stable or battle-tested enough for our needs (see this somewhat outdated article on CouchDB, for example). MySQL works. It doesn’t corrupt data. Replication works. We understand its limitations already. We like MySQL for storage, just not RDBMS usage patterns.After some deliberation, we decided to implement a “schema-less” storage system on top of MySQL rather than use a completely new storage system. This post attempts to describe the high-level details of the system. We are curious how other large sites have tackled these problems, and we thought some of the design work we have done might be useful to other developers.OverviewOur datastore stores schema-less bags of properties (e.g., JSON objects or Python dictionaries). The only required property of stored entities is id, a 16-byte UUID. The rest of the entity is opaque as far as the datastore is concerned. We can change the “schema” simply by storing new properties.We index data in these entities by storing indexes in separate MySQL tables. If we want to index three properties in each entity, we will have three MySQL tables – one for each index. If we want to stop using an index, we stop writing to that table from our code and, optionally, drop the table from MySQL. If we want a new index, we make a new MySQL table for that index and run a process to asynchronously populate the index without disrupting our live service.As a result, we end up having more tables than we had before, but adding and removing indexes is easy. We have heavily optimized the process that populates new indexes (which we call “The Cleaner”) so that it fills new indexes rapidly without disrupting the site. We can store new properties and index them in a day’s time rather than a week’s time, and we don’t need to swap MySQL masters and slaves or do any other scary operational work to make it happen.DetailsIn MySQL, our entities are stored in a table that looks like this:CREATE TABLE entities ( added_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, id BINARY(16) NOT NULL, updated TIMESTAMP NOT NULL, body MEDIUMBLOB, UNIQUE KEY (id), KEY (updated) ) ENGINE=InnoDB; The added_id column is present because InnoDB stores data rows physically in primary key order. The AUTO_INCREMENT primary key ensures new entities are written sequentially on disk after old entities, which helps for both read and write locality (new entities tend to be read more frequently than old entities since FriendFeed pages are ordered reverse-chronologically). Entity bodies are stored as zlib-compressed, pickled Python dictionaries.Indexes are stored in separate tables. To create a new index, we create a new table storing the attributes we want to index on all of our database shards. For example, a typical entity in FriendFeed might look like this:{ "id": "71f0c4d2291844cca2df6f486e96e37c", "user_id": "f48b0440ca0c4f66991c4d5f6a078eaf", "feed_id": "f48b0440ca0c4f66991c4d5f6a078eaf", "title": "We just launched a new backend system for FriendFeed!", "link": "http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c", "published": 1235697046, "updated": 1235697046, } We want to index the user_id attribute of these entities so we can render a page of all the entities a given user has posted. Our index table looks like this:CREATE TABLE index_user_id ( user_id BINARY(16) NOT NULL, entity_id BINARY(16) NOT NULL UNIQUE, PRIMARY KEY (user_id, entity_id) ) ENGINE=InnoDB; Our datastore automatically maintains indexes on your behalf, so to start an instance of our datastore that stores entities like the structure above with the given indexes, you would write (in Python):user_id_index = friendfeed.datastore.Index( table="index_user_id", properties=["user_id"], shard_on="user_id") datastore = friendfeed.datastore.DataStore( mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"], indexes=[user_id_index]) new_entity = { "id": binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c"), "user_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"), "feed_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"), "title": u"We just launched a new backend system for FriendFeed!", "link": u"http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c", "published": 1235697046, "updated": 1235697046, } datastore.put(new_entity) entity = datastore.get(binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c")) entity = user_id_index.get_all(datastore, user_id=binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf")) The Index class above looks for the user_id property in all entities and automatically maintains the index in the index_user_id table. Since our database is sharded, the shard_on argument is used to determine which shard the index gets stored on (in this case, entity["user_id"] % num_shards).You can query an index using the index instance (see user_id_index.get_all above). The datastore code does the “join” between the index_user_id table and the entities table in Python, by first querying the index_user_id tables on all database shards to get a list of entity IDs and then fetching those entity IDs from the entities table.To add a new index, e.g., on the link property, we would create a new table:CREATE TABLE index_link ( link VARCHAR(735) NOT NULL, entity_id BINARY(16) NOT NULL UNIQUE, PRIMARY KEY (link, entity_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; We would change our datastore initialization code to include this new index:user_id_index = friendfeed.datastore.Index( table="index_user_id", properties=["user_id"], shard_on="user_id") link_index = friendfeed.datastore.Index( table="index_link", properties=["link"], shard_on="link") datastore = friendfeed.datastore.DataStore( mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"], indexes=[user_id_index, link_index]) And we could populate the index asynchronously (even while serving live traffic) with:./rundatastorecleaner.py --index=index_link Consistency and AtomicitySince our database is sharded, and indexes for an entity can be stored on different shards than the entities themselves, consistency is an issue. What if the process crashes before it has written to all the index tables?Building a transaction protocol was appealing to the most ambitious of FriendFeed engineers, but we wanted to keep the system as simple as possible. We decided to loosen constraints such that: The property bag stored in the main entities table is canonical Indexes may not reflect the actual entity values Consequently, we write a new entity to the database with the following steps: Write the entity to the entities table, using the ACID properties of InnoDB Write the indexes to all of the index tables on all of the shards When we read from the index tables, we know they may not be accurate (i.e., they may reflect old property values if writing has not finished step 2). To ensure we don’t return invalid entities based on the constraints above, we use the index tables to determine which entities to read, but we re-apply the query filters on the entities themselves rather than trusting the integrity of the indexes: Read the entity_id from all of the index tables based on the query Read the entities from the entities table from the given entity IDs Filter (in Python) all of the entities that do not match the query conditions based on the actual property values To ensure that indexes are not missing perpetually and inconsistencies are eventually fixed, the “Cleaner” process I mentioned above runs continously over the entities table, writing missing indexes and cleaning up old and invalid indexes. It cleans recently updated entities first, so inconsistencies in the indexes get fixed fairly quickly (within a couple of seconds) in practice.PerformanceWe have optimized our primary indexes quite a bit in this new system, and we are quite pleased with the results. Here is a graph of FriendFeed page view latency for the past month (we launched the new backend a couple of days ago, as you can tell by the dramatic drop):In particular, the latency of our system is now remarkably stable, even during peak mid-day hours. Here is a graph of FriendFeed page view latency for the past 24 hours:Compare this to one week ago:The system has been really easy to work with so far. We have already changed the indexes a couple of times since we deployed the system, and we have started converting some of our biggest MySQL tables to use this new scheme so we can change their structure more liberally going forward.FROM:http://bret.appspot.com/entry/how-friendfeed-uses-mysql

负载均衡必须要考虑的八个方案 1、HTML静态化其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。2、图片服务器分离大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。3、数据库集群和库表散列大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。4、缓存缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。5、镜像镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。6、负载均衡负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。7、硬件四层交换第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚 IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。8、软件四层交换大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。FROM：CU

nginx防止盗链模块accesskey accesskey 源码包 点击这里下载.然后再ssh里把accesskey的源码解压 例如所有文件被解压在/data/accesskey/ 下.然后解压nginx源码 在常规./configure 的参数后 添加上 –add-module=/data/accesskey 就可以了然后就是配置nginx了 这里贴上独立的一段. accesskey on; accesskey_hashmethod md5; accesskey_arg "参数"; accesskey_signature "密码$remote_addr";把上面的参数改成你喜欢的 比如k密码改成比如123之类的.单独保存为一个文件 比如 acc.conf; 然后在需要的location下include这个conf文件即可 例如location /picture { include acc.conf; }如此这般设置要以后 还需要在php代码里算出这个k的值.<!--?php $ipkey= md5("配置文件里的密码".$_SERVER['REMOTE_ADDR']); ?--> <img src="/picture/t.jpg?k=&lt;?php echo $ipkey; ?&gt;" alt="" />

Nginx简单防御CC攻击 Nginx是一款轻量级的Web服务器，由俄罗斯的程序设计师Igor Sysoev所开发，最初供俄国大型的入口网站及搜寻引Rambler使用。 其特点是占有内存少，并发能力强，事实上Nginx的并发能力确实在同类型的网站服务器中表现较好。Nginx虽然可以比Apache处理更大的连接数，但是HTTP GET FLOOD针对的不仅仅是WEB服务器，还有数据库服务器。大量HTTP请求产生了大量的数据库查询，可以在几秒之内使数据库停止响应，系统负载升高，最终导致服务器当机。本文主要介绍Centos+Nginx下如何快速有效得防御CC攻击。至于如何安装Nginx就不详细介绍了，有兴趣的读者可以在Nginx官方网站（http://www.nginx.org/）下载源代码进行编译。如果你使用的是Centos5，也可以使用rpm包进行安装（http://centos.alt.ru/repository/centos/5/i386/nginx-stable-0.7.65-1.el5.i386.rpm）。1.        主动抑制 为了让Nginx支持更多的并发连接数，根据实际情况对工作线程数和每个工作线程支持的最大连接数进行调整。例如设置“worker_processes 10”和“worker_connections 1024”，那这台服务器支持的最大连接数就是10×1024=10240。 worker_processes 10; events { use epoll; worker_connections 10240; }Nginx 0.7开始提供了2个限制用户连接的模块：NginxHttpLimitZoneModule和NginxHttpLimitReqModule。 NginxHttpLimitZoneModule可以根据条件进行并发连接数控制。 例如可以定义以下代码： http { limit_zone   my_zone  $binary_remote_addr  10m; server { location /somedir/ { limit_conn   my_zone  1; } } } 其中“limit_zone  my_zone  $binary_remote_addr  10m”的意思是定义一个名称为my_zone的存储区域、my_zone中的内容为远程IP地址、my_zone的大小为10M；“location /somedir/”的意思是针对somedir目录应用规则；“limit_conn  my_zone  1”的意思是针对上面定义的my_zone记录区记录的IP地址在指定的目录中只能建立一个连接。NginxHttpLimitReqModule可以根据条件进行请求频率的控制。 例如可以定义以下代码： http { limit_req_zone  $binary_remote_addr  zone=my_req_zone:10m   rate=1r/s; ... server { ... location /somedir/ { limit_req_zone   zone= my_req_zone  burst=2; } 其中“limit_req_zone  $binary_remote_addr  zone=my_req_zone:10m  rate=1r/s”的意思是定义一个名称为my_req_zone的存储区域，my_req_zone内容为远程IP地址，my_req_zone大小为10M，my_req_zone中的平均请求速率只能为1个每秒；“location /somedir/”的意思是针对somedir目录应用规则；“limit_req_zone   zone= my_req_zone  burst=2”的意思是针对上面定义的my_req_zone记录区记录的IP地址在请求指定的目录中的内容时最高2个每秒的突发请求速率。当有连接触发上诉规则时，Nginx会报“503 Service Temporarily Unavailable”的错误，停止用户请求。返回一个503，对服务器来说影响不大，只占用一个nginx的线程而已，相对来说还是很划算的。为了测试效果，我将以上代码放入Nginx的配置文件，并编写了一个php文件显示phpinfo；另外还写了一个html文件，其中嵌入了多个iframe调用php文件。当我打开这个html文件了，可以看到只有一个iframe中的php文件正常显示了，其他的iframe都显示503错误。 应用举例（Discuz！） Discuz!是使用比较多的一个php论坛程序。以Discuz!7.0为例，程序目录下有比较多的可以直接访问的php文件，但其中最容易受到攻击的一般有index.php（首页）、forumdisplay.php（板块显示）、viewthread.php（帖子显示）。攻击者一般会对这些页面发起大量的请求，导致HTTP服务器连接数耗尽、mysql数据库停止响应，最终导致服务器崩溃。 为了防止上述页面被攻击，我们可以设定以下的规则进行防御： http { limit_zone   myzone_bbs  $binary_remote_addr  10m; limit_req_zone $binary_remote_addr zone=bbs:10m rate=1r/s; ... server { ... location ~ ^/bbs/(index|forumdisplay|viewthread).php$ { limit_conn   myzone_bbs  3; limit_req zone=bbs burst=2 nodelay; root           html; fastcgi_pass   unix:/dev/shm/php-cgi.sock; fastcgi_index  index.php; fastcgi_param  SCRIPT_FILENAME  /usr/share/nginx/html$fastcgi_script_name; include        fastcgi_params; } } } 应用这条规则后，bbs目录下的index.php、forumdisplay.php和viewthread.php这些页面同一个IP只许建立3个连接，并且每秒只能有1个请求（突发请求可以达到2个）。 虽然这样的规则一般来说对正常的用户不会产生影响（极少有人在1秒内打开3个页面），但是为了防止影响那些手快的用户访问，可以在nginx中自定义503页面，503页面对用户进行提示，然后自动刷新。 在Nginx中自定义503页面： error_page   503   /errpage/503.html; 503页面的源代码： <html> < head> < title>页面即将载入....</title> < meta http-equiv=content-type c> < META NAME="ROBOTS" C> < /head> < body bgcolor="#FFFFFF"> < table cellpadding="0" cellspacing="0" border="0" width="700" align="center" height="85%"> <tr align="center" valign="middle"> <td> <table cellpadding="10" cellspacing="0" border="0" width="80%" align="center" style="font-family: Verdana, Tahoma; color: #666666; font-size: 11px"> <tr> <td valign="middle" align="center" bgcolor="#EBEBEB"> <br /><b style="font-size: 16px">页面即将载入</b> <br /><br />你刷新页面的速度过快。请少安毋躁，页面即将载入... <br /><br />[<a href="javascript:window.location.reload();"><font color=#666666>立即重新载入</font></a>] <br /><br /> </td> </tr> </table> </td> </tr> < /table> < /body> < /html>< SCRIPT language=javascript> function update() { window.location.reload(); } setTimeout("update()",2000); < /script>2.        被动防御 虽然主动防御已经抵挡了大多数HTTP GET FLOOD攻击，但是道高一尺魔高一丈，攻击者会总会找到你薄弱的环节进行攻击。所以我们在这里也要介绍一下被动防御的一些方法。 1)        封IP地址 访问者通过浏览器正常访问网站，与服务器建立的连接一般不会超过20个，我们可以通过脚本禁止连接数过大的IP访问。 以下脚本通过netstat命令列举所有连接，将连接数最高的一个IP如果连接数超过150，则通过 iptables阻止访问： #!/bin/sh status=`netstat -na|awk '$5 ~ /[0-9]+:[0-9]+/ {print $5}' |awk -F ":" -- '{print $1}' |sort -n|uniq -c |sort -n|tail -n 1` NUM=`echo $status|awk '{print $1}'` IP=`echo $status|awk '{print $2}'` result=`echo "$NUM > 150" | bc` if [ $result = 1 ] then echo IP:$IP is over $NUM, BAN IT! /sbin/iptables -I INPUT -s $IP -j DROP fi运行crontab -e，将上述脚本添加到crontab每分钟自动运行： * * * * * /root/xxxx.sh 通过apache自带的ab工具进行服务器压力测试： ab -n 1000 -c 100 http://www.xxx.com/bbs/index.php 测试完成后，我们就可以看到系统中有IP被封的提示： [root@xxxxxx ~]#tail /var/spool/mail/root Content-Type: text/plain; charset=ANSI_X3.4-1968 Auto-Submitted: auto-generated X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/root> X-Cron-Env: <;PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=root> X-Cron-Env: <USER=root>IP:58.246.xx.xx is over 1047, BAN IT! 至此，又一次HTTP GET FLOOD防御成功。2)        根据特征码屏蔽请求（对CC攻击效果较好） 一般同一种CC攻击工具发起的攻击请求包总是相同的，而且和正常请求有所差异。 当服务器遭遇CC攻击时，我们可以快速查看日志，分析其请求的特征，比如User-agent。下面的是某一次CC攻击时的User-agent Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; MyIE 3.01)Cache-Control: no-store, must-revalidate 几乎没有正常的浏览器会在User-agent中带上“must-revalidate”这样的关键字。所以我们可以以这个为特征进行过滤，将User-agent中带有“must-revalidate”的请求全部拒绝访问： if ($http_user_agent ~ must-revalidate) { return 403; }本文主要介绍了nginx下的HTTP GET FLOOD防御，如果有不对的地方，希望大家可以向我提出。同时，也希望大家能够举一反三，把这种思路应用到apache、lighttpd等常见的web服务器中。

ApacheBench(ab)使用简介 ApacheBench 主要是用来测试阿帕奇服务器执行效率用的。安装好 apache 服务器套件后，进入 bin 目录，就可以找到该可执行文件 ab.exe 。         ApacheBench 可以针对某一特定 URL 模拟出连续的联机请求，同时还可以仿真出同时间点个数相同的联机请求，因而利用 ApacheBench 可帮助我们在网站开发期间仿真实际上线可能的情况，利用仿真出来的数据做为调整服务器设定或程序的依据。ab 用法如下Usage: ab [options] [http[s]://]hostname[:port]/path Options are:     -n requests     Number of requests to perform # 请求次数     -c concurrency  Number of multiple requests to make ＃同一时间发出多少个请求（并行连接）     -t timelimit    Seconds to max. wait for responses     -p postfile     File containing data to POST     -T content-type Content-type header for POSTing     -v verbosity    How much troubleshooting info to print     -w              Print out results in HTML tables     -i              Use HEAD instead of GET     -x attributes   String to insert as table attributes     -y attributes   String to insert as tr attributes     -z attributes   String to insert as td or th attributes     -C attribute    Add cookie, eg. 'Apache=1234. (repeatable)     -H attribute    Add Arbitrary header line, eg. 'Accept-Encoding: gzip'                     Inserted after all normal header lines. (repeatable)     -A attribute    Add Basic WWW Authentication, the attributes                     are a colon separated username and password.     -P attribute    Add Basic Proxy Authentication, the attributes                     are a colon separated username and password.     -X proxy:port   Proxyserver and port number to use     -V              Print version number and exit     -k              Use HTTP KeepAlive feature     -d              Do not show percentiles served table.     -S              Do not show confidence estimators and warnings.     -g filename     Output collected data to gnuplot format file.     -e filename     Output CSV file with percentages served     -s              Use httpS instead of HTTP (SSL)     -h              Display usage information (this message)基本用法 : ab -n 全部请求数 -c 并发数 测试 url 例 :ab -n 1000 -c 50 http://www.abc.com/a.php 得到结果类似于 ( 后面颜色字为中文翻译 ): Server Software:        Apache/2.0.55 Server Hostname:        localhost Server Port:            80 Document Path:          /1.php Document Length:        82522 bytes  # 请求文档大小 Concurrency Level:      50           # 并发数 Time taken for tests:   92.76140 seconds # 全部请求完成耗时 Complete requests:      10000          # 全部请求数 Failed requests:        1974           # 失败的请求   (Connect: 0, Length: 1974, Exceptions: 0) Write errors:           0 Total transferred:      827019400 bytes   # 总传输大小 HTML transferred:       825219400 bytes Requests per second:    108.61 [#/sec] (mean)   # 每秒请求数 ( 平均 ) Time per request:       460.381 [ms] (mean)   # 每次并发请求时间 ( 所有并发 ) Time per request:       9.208 [ms] (mean, across all concurrent requests)   # 每一请求时间 ( 并发平均 )   Transfer rate:          8771.39 [Kbytes/sec] received    # 传输速率 Connection Times (ms)    # 连接时间              min  mean[+/-sd] median   max Connect(# 连接 ):        0    0   2.1      0      46 Processing(# 处理 ):    31  458  94.7    438    1078 Waiting(# 等待 ):       15  437  87.5    422     938 Total:         31  458  94.7    438    1078 其它参数 : -n requests     全部请求数 -c concurrency   并发数 -t timelimit     最传等待回应时间 -p postfile     POST 数据文件 -T content-type POST Content-type -v verbosity    How much troubleshooting info to print -w              Print out results in HTML tables -i              Use HEAD instead of GET -x attributes   String to insert as table attributes -y attributes   String to insert as tr attributes -z attributes   String to insert as td or th attributes -C attribute     加入 cookie, eg. 'Apache=1234. (repeatable) -H attribute     加入 http 头 , eg. 'Accept-Encoding: gzip'                 Inserted after all normal header lines. (repeatable) -A attribute    http 验证 , 分隔传递用户名及密码 -P attribute    Add Basic Proxy Authentication, the attributes                 are a colon separated username and password. -X proxy:port   代理服务器 -V               查看 ab 版本 -k              Use HTTP KeepAlive feature -d              Do not show percentiles served table. -S              Do not show confidence estimators and warnings. -g filename     Output collected data to gnuplot format file. -e filename     Output CSV file with percentages served -h              Display usage information (this message)

linux文件夹信息显示(大小、排序.....) 方法一：ll ./* | sort -k 5 -n 从小到大排列，如果需要从小到大加-r选项即可方法二：ls -lSr 按文件大小降序排列 Linux 某个目录下的文件按大小排序1. df -lh2. du -s /usr/* | sort -rn 这是按字节排序3. du -sh /usr/* | sort -rn 这是按兆（M）来排序4.选出排在前面的10个 du -s /usr/* | sort -rn | head5.选出排在后面的10个 du -s /usr/* | sort -rn | tail说明：/usr/*也可以改成你想到达的任何目录 如/usr/local/zhou/resin 这个目录就可以写成 /usr/local/zhou/resin/* 文件夹所占大小 du . -H |grep

极客主机免费美国Cpanel空间 Val.so使用www.gke.cc的主机也有一段时间了，除了上次3天连续出问题补偿了1个月的使用外都很稳定非常不错，稀饭比较好说话一般不是很刁难的问题都会热心的帮忙解决！这次促销是webnx洛杉矶机房的服务器据悉配置为150M 1G流量，新手上路的博客练手还是不错的！为了避免恶意申请所以需要支付1元钱安装费！PS:如果流量空间不够用 ，可以发TK找稀饭要，一般的都会给调整的围观地址：http://client.gke.cc/cart.php?gid=2

Linux QQ mkidr qq cd qq wget http://home.xxsyzx.com/home/upfiles/myqq/myqq-src.zip unzip myqq-src.zip ./myqq QQ号 密码 yum update -y yum install gcc "fonts-chinese*" -y yum install make -y wget http://xiaoxia.org/home/upfiles/myqq3.19.zip unzip myqq3.19.zip cd myqq3.19 make -C src -flinux.mak clean all ./myqq

IE被篡改，IE设置无法保存，注册表无法修改解决方法 专门在安全模式下杀毒也不行未发现病毒~~~用IE修复~~系统修复~~能用的都用了~~还是不行~用windows7优化大师 进行修改~~对某些修改可能修改该了相关的注册表的时候~~提示windows7优化大师异常~~目标为  注册表修改没权限~~~  这下有点明白了~~开始--运行--regedit    进入注册表~~~展开注册表到HKEY_LOCAL_MACHINE、SOFTWARE、Microsoft、Internet Explore、rMain下，在右半部分窗口中找到串值“Start Page”双击 ，显示值为“about:blank”        正常    PS：如果不正常请手动改为这个~~~同理，展开注册表到HKEY_CURRENT_USER、Software、Microsoft、Internet Explorer、Main在右半部分窗口中找到串值“Start Page”，然后按上面所述方法处理。~~~~~~当我修改的时候~~提示不能修改的错误~~~~~为什么不能修改呢？？点MAIN  文件夹   发现 我的管理员账户没有权限~~那就添加被~~鼠标右键MAIN  权限  ~~~~出现以下图 点上图中的--添加--出现如图： 点高级~~ 选择第一个---然后点确定~~由回到第一个图了~~~那么选择你刚才添加的账户~~~在下面框里面~~所有权限都勾上~~~~点确定~~~这时以外发生了~~~提示MAIN无法修改权限~~当时我就崩溃了~~仔细看了又看~~~点图一中的  ----高级--试了试~~如下图： 点  ====有限权限====如下图： 点选择~~~~这里会重复以上的图片~~~添加起你的账户就行了~~按照上面的步骤~~添加起后~~~再重复 图一开始~~点下图中的添加~~~~再重复上面的步骤~~~添加就能成功~~~

Windows下MySql服务启动1067错误 1、打开my.ini文件，找到default-storage-engine=InnoDB这一行，把它改成default-storage-engine=MyISAM 2、删除在MySQL安装目录下的Data目录中的ib_logfile0ib_logfile1 3、找到在配置MySQL服务器时指定的InfoDB目录删除掉ibdata1 4、重新启动MySQL的Service net start mysql 在MySql的数据库存放目录下 有一个.err后缀的文件，里面记录了Mysql的错误，如果出现问题时很有必要查看一下！