在开发比特币应用时，除了使用自己搭建的节点，也可以利用第三方提供的比特币api，来获取市场行情、进行交易支付、查询账户余额等。这些第三方api不一定遵循标准的比特币rpc接口规范，但往往会利用自身的数据存储来增加比特币行情api、交易到账通知api、比特币rest api等，因此可以作为比特币应用开发的有益补充。本文介绍比特币开发人员常用的第三方比特币api的特点及访问地址。

如果要快速掌握比特币的对接与应用开发，推荐汇智网的在线互动课程：

Java比特币开发详解 —–
Php比特币开发详解 —–
C#比特币开发详解

1、blockchain.com比特币api

blockchain.com的比特币api是最受欢迎的比特币开发第三方api之一，提供支付处理、钱包服务、市场行情数据等功能。blockchain.com的比特币api同时还提供了针对多种语言的封装开发包，例如python、java、.net(c#)、ruby、php和node。

地址：https://www.blockchain.com/api

2、chain.so比特币api

chain.so的特色是除了提供比特币api，还额外提供的一些山寨币的api，例如莱特币、达世币等。

chian.so的比特币api，提供了获取地址、区块、市场行情等方面的功能，也支持交易广播。免费用户有5次请求/秒的限流。

地址：https://chain.so/api

3、block.io比特币api

block.io的比特币api包括基本的钱包服务、实时通知与即时支付转发等功能，支持web hook和websocket。对于免费用户，有3次/秒的限流。

地址：https://www.block.io/docs

4、chainquery.com比特币api

chainquery.com提供了比特币rpc api的web访问接口，你可以在网页里直接输入并执行标准的比特币rpc命令。

地址：http://chainquery.com/bitcoin-api

5、coinbase.com比特币api

作为老牌的交易所，coinbase.com也提供比特币api，功能包括生成比特币地址、买/卖比特币、钱包服务、实时行情接收、支付到账通知等。

接入coinbase.com的比特币api需要使用OAuth2，这是令人不开心的一点。

地址：https://developers.coinbase.com/

6、blockcypher.com比特币api

blockcyper.com提供rest风格的比特币api，功能涵盖地址、钱包、交易等常见需求，同时提供事件和hook机制，以便应用实时得到通知。

地址： https://www.blockcypher.com/dev/bitcoin/

7、bitcoinchain.com比特币api

bitcoinchain.com提供rest和stream两种方式的比特币api，功能包括基本的比特币区块链数据交互和市场行情通知。免费用户有1次请求/秒的限流。

地址：https://bitcoinchain.com/api

8、coindesk.com比特币api

coindesk.com专注于提供比特币价格指数方面的api，包括实时BPI数据和历史BPI数据。coindesk.com的比特币api不支持与比特币区块链的交互。

地址：https://www.coindesk.com/api

9、blockchain.info比特币api

作为专业的比特币区块链浏览服务提供商，blockchain.info专注于提供比特币区块数据查询api，如果你希望查询某个地址相关的历史交易信息，bitchain.info的比特币api是最佳选择。

地址：https://blockchain.info/q

10、btc.com比特币api

btc.com的比特币api主要提供比特币区块链交易数据的查询功能，但是不支持比特币交易的广播。

地址： https://btc.com/api-doc

今年区块链特别火，我也很火啊。我火什么呢。前几年，公众平台出现，还得花时间去学去看，后来小程序出现，又得花时间精力去学去看。现在比特币、以太坊等去中心化货币带起了区块链的发展。还得学。

没办法，技术改变师姐。不，是改变世界。

前些天看到python写的50行代码实现的简单区块链。今天让我们PHP也实现一下区块链的简单流程。

phper或其他人如有需要可加PHP区块链交流群(370648191/201923866)。

只有一个类、4个方法。可直接运行。

<?php/** * 简单的PHP区块链 * @author Yoper * @PHP技术交流QQ群 370648191 * @Email chen.yong.peng@foxmail.com * @wechat YoperMan */namespace common\library\block;/** * 区块结构 */class block{    private $index;    private $timestamp;    private $data;    private $previous_hash;    private $random_str;    private $hash;    public function __construct($index,$timestamp,$data,$random_str,$previous_hash)    {        $this->index=$index;        $this->timestamp=$timestamp;        $this->data=$data;        $this->previous_hash=$previous_hash;        $this->random_str=$random_str;        $this->hash=$this->hash_block();    }    public function __get($name){        return $this->$name;    }    private function hash_block(){        $str=$this->index.$this->timestamp.$this->data.$this->random_str.$this->previous_hash;        return hash("sha256",$str);    }}/** * 创世区块 * @return \common\library\block\block */function create_genesis_block(){    return new \common\library\block\block(0, time(),"第一个区块",0,0);}/** * 挖矿，生成下一个区块 * 这应该是一个复杂的算法，但为了简单，我们这里挖到前1位是数字就挖矿成功。 * @param \common\library\block\block $last_block_obj */function dig(\common\library\block\block $last_block_obj){    $random_str = $last_block_obj->hash.get_random();    $index=$last_block_obj->index+1;    $timestamp=time();    $data='I am block '.$index;    $block_obj = new \common\library\block\block($index,$timestamp,$data,$random_str,$last_block_obj->hash);        //前一位不是数字    if(!is_numeric($block_obj->hash{0})){        return false;    }    //数数字，返回块    return $block_obj;}/** * 验证区块 * 这也是一个复杂的过程，为了简单，我们这里直接返回正确 * @param array $data */function verify(\common\library\block\block $last_block_obj){    return true;}/** * 生成随机字符串 * @param int $len * @return string */function get_random($len=32){    $str="0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";    $key = "";    for($i=0;$i<$len;$i++)    {        $key.= $str{mt_rand(0,32)};//随机数    }    return $key;}  header("Content-type:text/html;charset=utf-8");//生成第一个区块$blockchain=[\common\library\block\create_genesis_block()];//模拟生成其他区块,我们直接循环生成。实际中，还需要跟踪互联网上多台机器上链的变化,像比特币会有工作量证明等算法，达到条件了才生成区块等//我们的链是一个数组，实际生产中应该保存下来$previous_block = $blockchain[0];for($i=0;$i<=10;$i++){    if(!($new_block=dig($previous_block))){        continue;    }    $blockchain[]=$new_block;    $previous_block=$new_block;        //告诉大家新增了一个区块    echo "区块已加入链中.新区块是 : {$new_block->index}<br/>";    echo "新区块哈希值是 : {$new_block->hash}<br/>";    print_r($new_block);    echo "<br/><br/>";}

以上文件可以直接运行。运行结果如下：

完善之后，就可以发行自己的货币或者智能合约了。

https://github.com/liexusong/blockchain-php/tree/v2.0

比特币的挖矿算法的流程。

区块头

首先挖矿算法的目标对象只是区块中的区块头，共80个字节，我们来看看区块头有哪些字段： 

注意：

1. Target（难度目标）：该区块工作量证明算法的难度目标
2. 其实区块头不包括Padding+Length部分，这个部分只是为了满足SHA256算法的使用条件。
3. 字段的不同颜色代表该字段内容变化频率。绿色：像Version、Target、以及Padding+Length(有约定俗成的标准)这些内容相对出块的速度来说变化频率很低；黄色：像hashPreBlock、hashMerkleRoot、Timestamp这些几乎与出块的速度一致的频率；红色：像Nonce这个的变化频率远远快与出块速率。

挖矿算法流程

为什么要做双重hash（SHA256(1)后还来个SHA256(2)）

The SHA256 hashing algorithm, like all hashes constructed using the Merkle-Damgård paradigm, is vulnerable to this attack. The length extension attack allows an attacker who knows SHA256(x) to calculate SHA256(x||y) without the knowledge of x. Although it is unclear how length extension attacks may make the Bitcoin protocol susceptible to harm, it is believed that Satoshi Nakamoto decided to play it safe and include the double hashing in his design.

Another explanation [6] for this double hashing is that 128 rounds of SHA256 may remain safe longer if in the far future, a practical pre-image or a partial pre-image attack was found against SHA256.

挖矿算法实现以及编码方式

Bitcoin mining uses the hashcash proof of work function; the hashcash algorithm requires the following parameters: a service string, a nonce, and a counter. In bitcoin the service string is encoded in the block header data structure, and includes a version field, the hash of the previous block, the root hash of the merkle tree of all transactions in the block, the current time, and the difficulty. Bitcoin stores the nonce in the extraNonce field which is part of the coinbase transaction, which is stored as the left most leaf node in the merkle tree (the coinbase is the special first transaction in the block). The counter parameter is small at 32-bits so each time it wraps the extraNonce field must be incremented (or otherwise changed) to avoid repeating work. The basics of the hashcash algorithm are quite easy to understand and it is described in more detail here. When mining bitcoin, the hashcash algorithm repeatedly hashes the block header while incrementing the counter & extraNonce fields. Incrementing the extraNonce field entails recomputing the merkle tree, as the coinbase transaction is the left most leaf node. The block is also occasionally updated as you are working on it.

A block header contains these fields:

The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren’t hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.

The compact format of target is a special kind of floating-point encoding using 3 bytes mantissa, the leading byte as exponent (where only the 5 lowest bits are used) and its base is 256. Most of these fields will be the same for all users. There might be some minor variation in the timestamps. The nonce will usually be different, but it increases in a strictly linear way. “Nonce” starts at 0 and is incremented for each hash. Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root.

Moreover, it is extremely unlikely for two people to have the same Merkle root because the first transaction in your block is a generation “sent” to one of your unique Bitcoin addresses. Since your block is different from everyone else’s blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network.

Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order.

For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, Block 125552. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:

>>> import hashlib
>>> header_hex = ("01000000" +
 "81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
 "e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +
 "c7f5d74d" +
 "f2b9441a" +
 "42a14695")
>>> header_bin = header_hex.decode('hex')
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
>>> hash.encode('hex_codec')
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
>>> hash[::-1].encode('hex_codec')
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'

Endianess

Note that the hash, which is a 256-bit number, has lots of leading zero bytes when stored or printed as a big-endian hexadecimal constant, but it has trailing zero bytes when stored or printed in little-endian. For example, if interpreted as a string and the lowest (or start of) the string address keeps lowest significant byte, it is little-endian.

The output of blockexplorer displays the hash values as big-endian numbers; notation for numbers is usual (leading digits are the most significant digits read from left to right).

For another example, here is a version in plain C without any optimization, threading or error checking.

Here is the same example in plain PHP without any optimization.

<?
  //This reverses and then swaps every other char
  function SwapOrder($in){
      $Split = str_split(strrev($in));
      $x='';
      for ($i = 0; $i < count($Split); $i+=2) {
          $x .= $Split[$i+1].$Split[$i];
      } 
      return $x;
  }
 
  //makes the littleEndian
  function littleEndian($value){
      return implode (unpack('H*',pack("V*",$value)));
  }
 
  $version = littleEndian(1);
  $prevBlockHash = SwapOrder('00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81');
  $rootHash = SwapOrder('2b12fcf1b09288fcaff797d71e950e71ae42b91e8bdb2304758dfcffc2b620e3');
  $time = littleEndian(1305998791);
  $bits = littleEndian(440711666); 
  $nonce = littleEndian(2504433986); 
 
  //concat it all
  $header_hex = $version . $prevBlockHash . $rootHash . $time . $bits . $nonce;
 
  //convert from hex to binary 
  $header_bin  = hex2bin($header_hex);
  //hash it then convert from hex to binary 
  $pass1 = hex2bin(  hash('sha256', $header_bin )  );
  //Hash it for the seconded time
  $pass2 = hash('sha256', $pass1);
  //fix the order
  $FinalHash = SwapOrder($pass2);
 
  echo   $FinalHash;
?>

Category: 

• Technical

我们通常衡量一个Web系统的吞吐率的指标是QPS（Query Per Second，每秒处理请求数），解决每秒数万次的高并发场景，这个指标非常关键。举个例子，我们假设处理一个业务请求平均响应时间为100ms，同时，系统内有20台Apache的Web服务器，配置MaxClients为500个（表示Apache的最大连接数目）。

那么，我们的Web系统的理论峰值QPS为（理想化的计算方式）：

20*500/0.1 = 100000 （10万QPS）

咦？我们的系统似乎很强大，1秒钟可以处理完10万的请求，5w/s的秒杀似乎是“纸老虎”哈。实际情况，当然没有这么理想。在高并发的实际场景下，机器都处于高负载的状态，在这个时候平均响应时间会被大大增加。

普通的一个p4的服务器每天最多能支持大约10万左右的IP，如果访问量超过10W那么需要专用的服务器才能解决，如果硬件不给力 软件怎么优化都是于事无补的。主要影响服务器的速度

有：网络-硬盘读写速度-内存大小-cpu处理速度。

就Web服务器而言，Apache打开了越多的连接进程，CPU需要处理的上下文切换也越多，额外增加了CPU的消耗，然后就直接导致平均响应时间增加。因此上述的MaxClient数目，要根据CPU、内存等硬件因素综合考虑，绝对不是越多越好。可以通过Apache自带的abench来测试一下，取一个合适的值。然后，我们选择内存操作级别的存储的Redis，在高并发的状态下，存储的响应时间至关重要。网络带宽虽然也是一个因素，不过，这种请求数据包一般比较小，一般很少成为请求的瓶颈。负载均衡成为系统瓶颈的情况比较少，在这里不做讨论哈。

那么问题来了，假设我们的系统，在5w/s的高并发状态下，平均响应时间从100ms变为250ms（实际情况，甚至更多）：

20*500/0.25 = 40000 （4万QPS）

于是，我们的系统剩下了4w的QPS，面对5w每秒的请求，中间相差了1w。

举个例子，高速路口，1秒钟来5部车，每秒通过5部车，高速路口运作正常。突然，这个路口1秒钟只能通过4部车，车流量仍然依旧，结果必定出现大塞车。（5条车道忽然变成4条车道的感觉）

同理，某一个秒内，20*500个可用连接进程都在满负荷工作中，却仍然有1万个新来请求，没有连接进程可用，系统陷入到异常状态也是预期之内。

其实在正常的非高并发的业务场景中，也有类似的情况出现，某个业务请求接口出现问题，响应时间极慢，将整个Web请求响应时间拉得很长，逐渐将Web服务器的可用连接数占满，其他正常的业务请求，无连接进程可用。

更可怕的问题是，是用户的行为特点，系统越是不可用，用户的点击越频繁，恶性循环最终导致“雪崩”（其中一台Web机器挂了，导致流量分散到其他正常工作的机器上，再导致正常的机器也挂，然后恶性循环），将整个Web系统拖垮。

3. 重启与过载保护

如果系统发生“雪崩”，贸然重启服务，是无法解决问题的。最常见的现象是，启动起来后，立刻挂掉。这个时候，最好在入口层将流量拒绝，然后再将重启。如果是redis/memcache这种服务也挂了，重启的时候需要注意“预热”，并且很可能需要比较长的时间。

秒杀和抢购的场景，流量往往是超乎我们系统的准备和想象的。这个时候，过载保护是必要的。如果检测到系统满负载状态，拒绝请求也是一种保护措施。在前端设置过滤是最简单的方式，但是，这种做法是被用户“千夫所指”的行为。更合适一点的是，将过载保护设置在CGI入口层，快速将客户的直接请求返回

高并发下的数据安全

我们知道在多线程写入同一个文件的时候，会存现“线程安全”的问题（多个线程同时运行同一段代码，如果每次运行结果和单线程运行的结果是一样的，结果和预期相同，就是线程安全的）。如果是MySQL数据库，可以使用它自带的锁机制很好的解决问题，但是，在大规模并发的场景中，是不推荐使用MySQL的。秒杀和抢购的场景中，还有另外一个问题，就是“超发”，如果在这方面控制不慎，会产生发送过多的情况。我们也曾经听说过，某些电商搞抢购活动，买家成功拍下后，商家却不承认订单有效，拒绝发货。这里的问题，也许并不一定是商家奸诈，而是系统技术层面存在超发风险导致的。

1. 超发的原因

假设某个抢购场景中，我们一共只有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。（同文章前面说的场景）

在上面的这个图中，就导致了并发用户B也“抢购成功”，多让一个人获得了商品。这种场景，在高并发的情况下非常容易出现。

优化方案1：将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false

2. 悲观锁思路

解决线程安全的思路很多，可以从“悲观锁”的方向开始讨论。

悲观锁，也就是在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。

虽然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。

优化方案2：使用MySQL的事务，锁住操作的行

3. FIFO队列思路

那好，那么我们稍微修改一下上面的场景，我们直接将请求放入队列中的，采用FIFO（First Input First Output，先进先出），这样的话，我们就不会导致某些请求永远获取不到锁。看到这里，是不是有点强行将多线程变成单线程的感觉哈。

然后，我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但是，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。

4. 文件锁的思路

对于日IP不高或者说并发数不是很大的应用，一般不用考虑这些！用一般的文件操作方法完全没有问题。但如果并发高，在我们对文件进行读写操作时，很有可能多个进程对进一文件进行操作，如果这时不对文件的访问进行相应的独占，就容易造成数据丢失

优化方案4：使用非阻塞的文件排他锁

5. 乐观锁思路

这个时候，我们就可以讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话，我们就不需要考虑队列的问题，不过，它会增大CPU的计算开销。但是，综合来说，这是一个比较好的解决方案。

有很多软件和服务都“乐观锁”功能的支持，例如Redis中的watch就是其中之一。通过这个实现，我们保证了数据的安全。

优化方案5：Redis中的watch

PHP解决网站大数据大流量与高并发

第一个要说的就是数据库，首先要有一个很好的架构，查询尽量不用* 避免相关子查询 给经常查询的添加索引 用排序来取代非顺序存取，如果条件允许 ，一般MySQL服务器最好安装在Linux操作系统中 。关于apache和nginx在高并发的情况下推荐使用nginx，ginx是Apache服务器不错的替代品。nginx内存消耗少 官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数。php方面不需要的模块尽量关闭，使用memcached，Memcached 是一个高性能的分布式内存对象缓存系统，不使用数据库直接从内存当中调数据，这样大大提升了速度，iiS或Apache启用GZIP压缩优化网站，压缩网站内容大大节省网站流量。

第二，禁止外部的盗链。

外部网站的图片或者文件盗链往往会带来大量的负载压力，因此应该严格限制外部对
于自身的图片或者文件盗链，好在目前可以简单地通过refer来控制盗链，Apache自
己就可以通过配置来禁止盗链，IIS也有一些第三方的ISAPI可以实现同样的功能。当
然，伪造refer也可以通过代码来实现盗链，不过目前蓄意伪造refer盗链的还不多，
可以先不去考虑，或者使用非技术手段来解决，比如在图片上增加水印。

第三，控制大文件的下载。

大文件的下载会占用很大的流量，并且对于非SCSI硬盘来说，大量文件下载会消耗
CPU，使得网站响应能力下降。因此，尽量不要提供超过2M的大文件下载，如果需要
提供，建议将大文件放在另外一台服务器上。

第四，使用不同主机分流主要流量

将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得RSS文件占用
流量大，那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上，这
样别人访问的流量压力就大多集中在FeedBurner的主机上，RSS就不占用太多资源了

第五，使用不同主机分流主要流量
将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得RSS文件占用流量大，那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上，这样别人访问的流量压力就大多集中在FeedBurner的主机上，RSS就不占用太多资源了。

第六，使用流量分析统计软件。
在网站上安装一个流量分析统计软件，可以即时知道哪些地方耗费了大量流量，哪些页面需要再进行优化，因此，解决流量问题还需要进行精确的统计分析才可以。比如：Google Analytics（Google分析）。

高并发和高负载的约束条件：硬件、部署、操作系统、Web 服务器、PHP、MySQL、测试

部署：服务器分离、数据库集群和库表散列、镜像、负载均衡

负载均衡分类： 1)、DNS轮循 2）代理服务器负载均衡 3）地址转换网关负载均衡 4）NAT负载均衡 5）反向代理负载均衡 6）混合型负载均衡

部署方案1：

适用范围：静态内容为主体的网站和应用系统；对系统安全要求较高的网站和应用系统。

Main Server：主服务器

承载程序的主体运行压力，处理网站或应用系统中的动态请求；

将静态页面推送至多个发布服务器；

将附件文件推送至文件服务器；

安全要求较高，以静态为主的网站，可将服务器置于内网屏蔽外网的访问。

DB Server：数据库服务器

承载数据库读写压力；

只与主服务器进行数据量交换，屏蔽外网访问。

File/Video Server：文件/视频服务器

承载系统中占用系统资源和带宽资源较大的数据流；

作为大附件的存储和读写仓库；

作为视频服务器将具备视频自动处理能力。

发布服务器组：

只负责静态页面的发布，承载绝大多数的Web请求；

通过Nginx进行负载均衡部署。

部署方案2：

适用范围：以动态交互内容为主体的网站或应用系统；负载压力较大，且预算比较充足的网站或应用系统；

Web服务器组：

Web服务无主从关系，属平行冗余设计；

通过前端负载均衡设备或Nginx反向代理实现负载均衡；

划分专用文件服务器/视频服务器有效分离轻/重总线；

每台Web服务器可通过DEC可实现连接所有数据库，同时划分主从。

数据库服务器组：

相对均衡的承载数据库读写压力；

通过数据库物理文件的映射实现多数据库的数据同步。

共享磁盘/磁盘阵列

将用于数据物理文件的统一读写

用于大型附件的存储仓库

通过自身物理磁盘的均衡和冗余，确保整体系统的IO效率和数据安全；

方案特性：

通过前端负载均衡，合理分配Web压力；

通过文件/视频服务器与常规Web服务器的分离，合理分配轻重数据流；

通过数据库服务器组，合理分配数据库IO压力；

每台Web服务器通常只连接一台数据库服务器，通过DEC的心跳检测，可在极短时间内自动切换至冗余数据库服务器；

磁盘阵列的引入，大幅提升系统IO效率的同时，极大增强了数据安全性。

Web服务器：

Web服务器很大一部分资源占用来自于处理Web请求，通常情况下这也就是Apache产生的压力，在高并发连接的情况下，Nginx是Apache服务器不错的替代品。Nginx (“engine x”) 是俄罗斯人编写的一款高性能的 HTTP 和反向代理服务器。在国内，已经有新浪、搜狐通行证、网易新闻、网易博客、金山逍遥网、金山爱词霸、校内网、YUPOO相册、豆瓣、迅雷看看等多家网站、 频道使用 Nginx 服务器。

Nginx的优势：

高并发连接：官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数。

内存消耗少：在3万并发连接下，开启的10个Nginx 进程才消耗150M内存（15M*10=150M）。

内置的健康检查功能：如果 Nginx Proxy 后端的某台 Web 服务器宕机了，不会影响前端访问。

策略：相对于老牌的Apache，我们选择Lighttpd和Nginx这些具有更小的资源占用率和更高的负载能力的web服务器。

Mysql：

MySQL本身具备了很强的负载能力，MySQL优化是一项很复杂的工作，因为这最终需要对系统优化的很好理解。大家都知道数据库工作就是大量的、 短时的查询和读写，除了程序开发时需要注意建立索引、提高查询效率等软件开发技巧之外，从硬件设施的角度影响MySQL执行效率最主要来自于磁盘搜索、磁盘IO水平、CPU周期、内存带宽。

　　根据服务器上的硬件和软件条件进行MySQl优化。MySQL优化的核心在于系统资源的分配，这不等于无限制的给MySQL分配更多的资源。在MySQL配置文件中我们介绍几个最值得关注的参数：

改变索引缓冲区长度(key_buffer)

改变表长(read_buffer_size)

设定打开表的数目的最大值(table_cache)

对缓长查询设定一个时间限制(long_query_time)

如果条件允许 ，一般MySQL服务器最好安装在Linux操作系统中，而不是安装在FreeBSD中。
策略： MySQL优化需要根据业务系统的数据库读写特性和服务器硬件配置，制定不同的优化方案，并且可以根据需要部署MySQL的主从结构。

PHP：

1、加载尽可能少的模块；

2、如果是在windows平台下，尽可能使用IIS或者Nginx来替代我们平常用的Apache；

3、安装加速器（都是通过缓存php代码预编译的结果和数据库结果来提高php代码的执行速度）
eAccelerator，eAccelerator是一个自由开放源码php加速器，优化和动态内容缓存，提高了性能php脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。

Apc：Alternative PHP Cache（APC）是 PHP 的一个免费公开的优化代码缓存。它用来提供免费，公开并且强健的架构来缓存和优化 PHP 的中间代码。

memcache：memcache是由Danga Interactive开发的，高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据库负载，提升访问速度。主要机制是通过在内存里维护一个统 一的巨大的hash表，Memcache能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等

Xcache：国人开发的缓存器，

策略： 为PHP安装加速器。

代理服务器（缓存服务器）：

Squid Cache（简称为Squid）是一个流行的自由软件（GNU通用公共许可证）的代理服务器和Web缓存服务器。Squid有广泛的用途，从作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度，到为一组人共享网络资源而缓存万维网，域名系统和其他网络搜索，到通过过滤流量帮助网络安全，到局域网通过代理网。Squid主要设计用于在Unix一类系统运行。

策略：安装Squid 反向代理服务器，能够大幅度提高服务器效率。

压力测试：压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。
压力测试工具：webbench，ApacheBench等

漏洞测试：在我们的系统中漏洞主要包括：sql注入漏洞，xss跨站脚本攻击等。安全方面还包括系统软件，如操作系统漏洞，mysql、apache等的漏洞，一般可以通过升级来解决。

漏洞测试工具：Acunetix Web Vulnerability Scanner

​​​做了个爬虫，因为PHP是单线程，所以爬取速度较慢，故使用了pthreads多线程，实现多线程爬取

pthreads扩展下载地址：http://windows.php.net/downloads/pecl/releases/pthreads

扩展文档：http://docs.php.net/manual/zh/book.pthreads.php

多线程代码

namespace app\api\controller\v1;
use think\Db; //此处的Db类都以失效，试了多种引入方式都不行
use think\Cache; //同理
use think\Controller;
class  Curl  extends \Thread
{
     public $url;
    public $result;
    public function __construct($url) {
        $this->url = $url;
    }
   //线程运行
    public function run() {
        if ($this->url) {
            $this->result = $this->doshu($this->url);

        }
    }
    public function doshu($url){
        return file_get_contents($url); //所需要访问的网址
    }
}

遇到的问题，线程中使用不了数据库，不知道什么原因，知道的大神可以解释一下，我用了访问内部的url来实现数据写入

public function doZhiHu1(){

//多个本地网址
        $urls = array(‘http://localhost/shopapi/api/v1.index/doZhiHu2’,
            ‘http://localhost/shopapi/api/v1.index/doZhiHu3’,
            ‘http://localhost/shopapi/api/v1.index/doZhiHu4’,
            ‘http://localhost/shopapi/api/v1.index/doZhiHu5’,
            ‘http://localhost/shopapi/api/v1.index/doZhiHu6’);
        foreach ($urls as $key=>$url) {
            $workers[$key] = new curl($url); //new一个新的线程
            $workers[$key]->start(); //开始运行
        }
        foreach ($workers as $key=>$worker) {
            while($workers[$key]->isRunning()) { //查看线程的状态
                usleep(100);  
            }
            if ($workers[$key]->join()) { //等待线程执行结束
                var_dump($workers[$key]->result);
            }
        }
    }

转发来自：https://www.cnblogs.com/walblog/articles/8476579.html（咸鱼想翻身）

我们通常衡量一个Web系统的吞吐率的指标是QPS（Query Per Second，每秒处理请求数），解决每秒数万次的高并发场景，这个指标非常关键。举个例子，我们假设处理一个业务请求平均响应时间为100ms，同时，系统内有20台Apache的Web服务器，配置MaxClients为500个（表示Apache的最大连接数目）。

那么，我们的Web系统的理论峰值QPS为（理想化的计算方式）：

20*500/0.1 = 100000 （10万QPS）

咦？我们的系统似乎很强大，1秒钟可以处理完10万的请求，5w/s的秒杀似乎是“纸老虎”哈。实际情况，当然没有这么理想。在高并发的实际场景下，机器都处于高负载的状态，在这个时候平均响应时间会被大大增加。

普通的一个p4的服务器每天最多能支持大约10万左右的IP，如果访问量超过10W那么需要专用的服务器才能解决，如果硬件不给力 软件怎么优化都是于事无补的。主要影响服务器的速度

有：网络-硬盘读写速度-内存大小-cpu处理速度。

就Web服务器而言，Apache打开了越多的连接进程，CPU需要处理的上下文切换也越多，额外增加了CPU的消耗，然后就直接导致平均响应时间增加。因此上述的MaxClient数目，要根据CPU、内存等硬件因素综合考虑，绝对不是越多越好。可以通过Apache自带的abench来测试一下，取一个合适的值。然后，我们选择内存操作级别的存储的Redis，在高并发的状态下，存储的响应时间至关重要。网络带宽虽然也是一个因素，不过，这种请求数据包一般比较小，一般很少成为请求的瓶颈。负载均衡成为系统瓶颈的情况比较少，在这里不做讨论哈。

那么问题来了，假设我们的系统，在5w/s的高并发状态下，平均响应时间从100ms变为250ms（实际情况，甚至更多）：

20*500/0.25 = 40000 （4万QPS）

于是，我们的系统剩下了4w的QPS，面对5w每秒的请求，中间相差了1w。

举个例子，高速路口，1秒钟来5部车，每秒通过5部车，高速路口运作正常。突然，这个路口1秒钟只能通过4部车，车流量仍然依旧，结果必定出现大塞车。（5条车道忽然变成4条车道的感觉）

同理，某一个秒内，20*500个可用连接进程都在满负荷工作中，却仍然有1万个新来请求，没有连接进程可用，系统陷入到异常状态也是预期之内。

其实在正常的非高并发的业务场景中，也有类似的情况出现，某个业务请求接口出现问题，响应时间极慢，将整个Web请求响应时间拉得很长，逐渐将Web服务器的可用连接数占满，其他正常的业务请求，无连接进程可用。

更可怕的问题是，是用户的行为特点，系统越是不可用，用户的点击越频繁，恶性循环最终导致“雪崩”（其中一台Web机器挂了，导致流量分散到其他正常工作的机器上，再导致正常的机器也挂，然后恶性循环），将整个Web系统拖垮。

3. 重启与过载保护

如果系统发生“雪崩”，贸然重启服务，是无法解决问题的。最常见的现象是，启动起来后，立刻挂掉。这个时候，最好在入口层将流量拒绝，然后再将重启。如果是redis/memcache这种服务也挂了，重启的时候需要注意“预热”，并且很可能需要比较长的时间。

秒杀和抢购的场景，流量往往是超乎我们系统的准备和想象的。这个时候，过载保护是必要的。如果检测到系统满负载状态，拒绝请求也是一种保护措施。在前端设置过滤是最简单的方式，但是，这种做法是被用户“千夫所指”的行为。更合适一点的是，将过载保护设置在CGI入口层，快速将客户的直接请求返回

高并发下的数据安全

我们知道在多线程写入同一个文件的时候，会存现“线程安全”的问题（多个线程同时运行同一段代码，如果每次运行结果和单线程运行的结果是一样的，结果和预期相同，就是线程安全的）。如果是MySQL数据库，可以使用它自带的锁机制很好的解决问题，但是，在大规模并发的场景中，是不推荐使用MySQL的。秒杀和抢购的场景中，还有另外一个问题，就是“超发”，如果在这方面控制不慎，会产生发送过多的情况。我们也曾经听说过，某些电商搞抢购活动，买家成功拍下后，商家却不承认订单有效，拒绝发货。这里的问题，也许并不一定是商家奸诈，而是系统技术层面存在超发风险导致的。

1. 超发的原因

假设某个抢购场景中，我们一共只有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。（同文章前面说的场景）

在上面的这个图中，就导致了并发用户B也“抢购成功”，多让一个人获得了商品。这种场景，在高并发的情况下非常容易出现。

优化方案1：将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false

 1 <?php
 2 //优化方案1：将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false
 3 include('./mysql.php');
 4 $username = 'wang'.rand(0,1000);
 5 //生成唯一订单
 6 function build_order_no(){
 7   return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
 8 }
 9 //记录日志
10 function insertLog($event,$type=0,$username){
11     global $conn;
12     $sql="insert into ih_log(event,type,usernma)
13     values('$event','$type','$username')";
14     return mysqli_query($conn,$sql);
15 }
16 function insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number)
17 {
18       global $conn;
19       $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price,username,number)
20       values('$order_sn','$user_id','$goods_id','$sku_id','$price','$username','$number')";
21      return  mysqli_query($conn,$sql);
22 }
23 //模拟下单操作
24 //库存是否大于0
25 $sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id' ";
26 $rs=mysqli_query($conn,$sql);
27 $row = $rs->fetch_assoc();
28   if($row['number']>0){//高并发下会导致超卖
29       if($row['number']<$number){
30         return insertLog('库存不够',3,$username);
31       }
32       $order_sn=build_order_no();
33       //库存减少
34       $sql="update ih_store set number=number-{$number} where sku_id='$sku_id' and number>0";
35       $store_rs=mysqli_query($conn,$sql);
36       if($store_rs){
37           //生成订单
38           insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number);
39           insertLog('库存减少成功',1,$username);
40       }else{
41           insertLog('库存减少失败',2,$username);
42       }
43   }else{
44       insertLog('库存不够',3,$username);
45   }
46 ?>

2. 悲观锁思路

解决线程安全的思路很多，可以从“悲观锁”的方向开始讨论。

悲观锁，也就是在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。

虽然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。

优化方案2：使用MySQL的事务，锁住操作的行

 1 <?php
 2 //优化方案2：使用MySQL的事务，锁住操作的行
 3 include('./mysql.php');
 4 //生成唯一订单号
 5 function build_order_no(){
 6   return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
 7 }
 8 //记录日志
 9 function insertLog($event,$type=0){
10     global $conn;
11     $sql="insert into ih_log(event,type)
12     values('$event','$type')";
13     mysqli_query($conn,$sql);
14 }
15 //模拟下单操作
16 //库存是否大于0
17 mysqli_query($conn,"BEGIN");  //开始事务
18 $sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id' FOR UPDATE";//此时这条记录被锁住,其它事务必须等待此次事务提交后才能执行
19 $rs=mysqli_query($conn,$sql);
20 $row=$rs->fetch_assoc();
21 if($row['number']>0){
22     //生成订单
23     $order_sn=build_order_no();
24     $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
25     values('$order_sn','$user_id','$goods_id','$sku_id','$price')";
26     $order_rs=mysqli_query($conn,$sql);
27     //库存减少
28     $sql="update ih_store set number=number-{$number} where sku_id='$sku_id'";
29     $store_rs=mysqli_query($conn,$sql);
30     if($store_rs){
31       echo '库存减少成功';
32         insertLog('库存减少成功');
33         mysqli_query($conn,"COMMIT");//事务提交即解锁
34     }else{
35       echo '库存减少失败';
36         insertLog('库存减少失败');
37     }
38 }else{
39   echo '库存不够';
40     insertLog('库存不够');
41     mysqli_query($conn,"ROLLBACK");
42 }
43 ?>

3. FIFO队列思路

那好，那么我们稍微修改一下上面的场景，我们直接将请求放入队列中的，采用FIFO（First Input First Output，先进先出），这样的话，我们就不会导致某些请求永远获取不到锁。看到这里，是不是有点强行将多线程变成单线程的感觉哈。

然后，我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但是，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。

4. 文件锁的思路

对于日IP不高或者说并发数不是很大的应用，一般不用考虑这些！用一般的文件操作方法完全没有问题。但如果并发高，在我们对文件进行读写操作时，很有可能多个进程对进一文件进行操作，如果这时不对文件的访问进行相应的独占，就容易造成数据丢失

优化方案4：使用非阻塞的文件排他锁

 1 <?php
 2 //优化方案4：使用非阻塞的文件排他锁
 3 include ('./mysql.php');
 4 //生成唯一订单号
 5 function build_order_no(){
 6   return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
 7 }
 8 //记录日志
 9 function insertLog($event,$type=0){
10     global $conn;
11     $sql="insert into ih_log(event,type)
12     values('$event','$type')";
13     mysqli_query($conn,$sql);
14 }
15 $fp = fopen("lock.txt", "w+");
16 if(!flock($fp,LOCK_EX | LOCK_NB)){
17     echo "系统繁忙，请稍后再试";
18     return;
19 }
20 //下单
21 $sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id'";
22 $rs =  mysqli_query($conn,$sql);
23 $row = $rs->fetch_assoc();
24 if($row['number']>0){//库存是否大于0
25     //模拟下单操作
26     $order_sn=build_order_no();
27     $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
28     values('$order_sn','$user_id','$goods_id','$sku_id','$price')";
29     $order_rs =  mysqli_query($conn,$sql);
30     //库存减少
31     $sql="update ih_store set number=number-{$number} where sku_id='$sku_id'";
32     $store_rs =  mysqli_query($conn,$sql);
33     if($store_rs){
34       echo '库存减少成功';
35         insertLog('库存减少成功');
36         flock($fp,LOCK_UN);//释放锁
37     }else{
38       echo '库存减少失败';
39         insertLog('库存减少失败');
40     }
41 }else{
42   echo '库存不够';
43     insertLog('库存不够');
44 }
45 fclose($fp);
46  ?>

 1 <?php
 2 //优化方案4：使用非阻塞的文件排他锁
 3 include ('./mysql.php');
 4 //生成唯一订单号
 5 function build_order_no(){
 6   return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
 7 }
 8 //记录日志
 9 function insertLog($event,$type=0){
10     global $conn;
11     $sql="insert into ih_log(event,type)
12     values('$event','$type')";
13     mysqli_query($conn,$sql);
14 }
15 $fp = fopen("lock.txt", "w+");
16 if(!flock($fp,LOCK_EX | LOCK_NB)){
17     echo "系统繁忙，请稍后再试";
18     return;
19 }
20 //下单
21 $sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id'";
22 $rs =  mysqli_query($conn,$sql);
23 $row = $rs->fetch_assoc();
24 if($row['number']>0){//库存是否大于0
25     //模拟下单操作
26     $order_sn=build_order_no();
27     $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
28     values('$order_sn','$user_id','$goods_id','$sku_id','$price')";
29     $order_rs =  mysqli_query($conn,$sql);
30     //库存减少
31     $sql="update ih_store set number=number-{$number} where sku_id='$sku_id'";
32     $store_rs =  mysqli_query($conn,$sql);
33     if($store_rs){
34       echo '库存减少成功';
35         insertLog('库存减少成功');
36         flock($fp,LOCK_UN);//释放锁
37     }else{
38       echo '库存减少失败';
39         insertLog('库存减少失败');
40     }
41 }else{
42   echo '库存不够';
43     insertLog('库存不够');
44 }
45 fclose($fp);
46  ?>

5. 乐观锁思路

这个时候，我们就可以讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话，我们就不需要考虑队列的问题，不过，它会增大CPU的计算开销。但是，综合来说，这是一个比较好的解决方案。

有很多软件和服务都“乐观锁”功能的支持，例如Redis中的watch就是其中之一。通过这个实现，我们保证了数据的安全。

优化方案5：Redis中的watch

 1 <?php
 2 $redis = new redis();
 3  $result = $redis->connect('127.0.0.1', 6379);
 4  echo $mywatchkey = $redis->get("mywatchkey");
 5 /*
 6   //插入抢购数据
 7  if($mywatchkey>0)
 8  {
 9      $redis->watch("mywatchkey");
10   //启动一个新的事务。
11     $redis->multi();
12    $redis->set("mywatchkey",$mywatchkey-1);
13    $result = $redis->exec();
14    if($result) {
15       $redis->hSet("watchkeylist","user_".mt_rand(1,99999),time());
16       $watchkeylist = $redis->hGetAll("watchkeylist");
17         echo "抢购成功！<br/>";
18         $re = $mywatchkey - 1;  
19         echo "剩余数量：".$re."<br/>";
20         echo "用户列表：<pre>";
21         print_r($watchkeylist);
22    }else{
23       echo "手气不好，再抢购！";exit;
24    } 
25  }else{
26      // $redis->hSet("watchkeylist","user_".mt_rand(1,99999),"12");
27      //  $watchkeylist = $redis->hGetAll("watchkeylist");
28         echo "fail！<br/>";   
29         echo ".no result<br/>";
30         echo "用户列表：<pre>";
31       //  var_dump($watchkeylist); 
32  }*/
33 $rob_total = 100;   //抢购数量
34 if($mywatchkey<=$rob_total){
35     $redis->watch("mywatchkey");
36     $redis->multi(); //在当前连接上启动一个新的事务。
37     //插入抢购数据
38     $redis->set("mywatchkey",$mywatchkey+1);
39     $rob_result = $redis->exec();
40     if($rob_result){
41          $redis->hSet("watchkeylist","user_".mt_rand(1, 9999),$mywatchkey);
42         $mywatchlist = $redis->hGetAll("watchkeylist");
43         echo "抢购成功！<br/>";
44       
45         echo "剩余数量：".($rob_total-$mywatchkey-1)."<br/>";
46         echo "用户列表：<pre>";
47         var_dump($mywatchlist);
48     }else{
49           $redis->hSet("watchkeylist","user_".mt_rand(1, 9999),'meiqiangdao');
50         echo "手气不好，再抢购！";exit;
51     }
52 }
53 ?>

生活步步是坎坷，笑到最后是大哥。