Appearance
系统优化与分布式
DZ-SHOP的单机（4核8G）QPS（Queries Per Second，每秒查询率）在500-600之间，TPS（Transactions Per Second，每秒事务数）在300-400之间，如果超过该并发数量，则需要升级服务器或采用分布式部署方案。
说明
建议
我们建议直接采购云服务来部署而不是购买服务器后托管。
正常情况下，需要根据项目的具体情况来做分布式部署方案。由于分布式部署涉及的知识点太多，我们假设您已经有分布式搭建的经验，下面将根据不同的情况来简单说明。
请求并发
当请求量超过单机承载能力的时候，则需要采用分布式部署。
以阿里云为例，你需要采购以下产品来搭建一个简单的分布式：
- 负载均衡（也可以使用ECS自己搭建）
- 两台或以上的ECS
- RDS、PolarDB、PolarDB-X或OceanBase（后两个为分布式数据库）
- Redis（推荐使用Redis；如果偏向本地缓存，可以将整个runtime文件夹映射到NAS，用来保证缓存一致性）
- OSS（如果偏向本地文件存储，可以将整个web/attachment文件夹映射到NAS，用来保证所有服务器均可访问）
建议
并发能力更多考验的是CPU负载能力，有能力的公司应尽量采用核心数更高的CPU，如8核16G，16核32G的服务器，并根据CPU核心数来调整nginx的负载能力。
带宽优化
一个Web应用，最耗费流量的是图片、音频、视频等内容。为了防止带宽问题导致的访问缓慢或者内容呈现缓慢，应尽量将图片、音频、视频采用云存储+CDN。比如阿里OSS、腾讯COS、七牛等等。
数据库
以阿里云为例，阿里云的RDS最大支持8核16G，10000写并发，这对于95%的企业来说都已经足够了。在实际测试中发现，数据库读写达到峰值读写并发未发现慢SQL。在超过10000秒级并发之后，根据具体业务，可以优先考虑主从架构，根据具体情况使用主从数据库。在主从架构都无法满足的业务情况下，应考虑使用分布式数据库。当然你可以使用像 MyCat 等产品自行搭建分布式数据库。
主从配置非常简单，且不用更改任何逻辑代码。你可以在config/common/main-local.php中配置db项设置主从数据库，例如：
php
return [
'components' => [
'db' => [
// 主库的配置
'class' => 'yii\db\Connection',
'dsn' => 'dsn for slave master',
'username' => 'master',
'password' => '',
// 从库的通用配置
'slaveConfig' => [
'username' => 'slave',
'password' => '',
'attributes' => [
// 使用一个更小的连接超时
PDO::ATTR_TIMEOUT => 10,
],
],
// 从库的配置列表
'slaves' => [
['dsn' => 'dsn for slave server 1'],
['dsn' => 'dsn for slave server 2'],
['dsn' => 'dsn for slave server 3'],
['dsn' => 'dsn for slave server 4'],
],
],
]
];性能优化
DZ-SHOP已经在代码上做了大量优化。
如果需要二次开发，可以点击了解性能优化的参考方案。
解耦
DZ-SHOP的定时任务、队列均属于解耦方案。一般来说，这些解耦方案已经足够。
当然，也可以使用微服务的方式进行逻辑分拆，比如使用腾讯的RPC框架Tars。但是由微服务框架的复杂性，非超大型应用不推荐使用。
限流削峰
为了应对突然的请求暴增导致服务器崩溃，限流削峰是必要的。
DZ-SHOP已经内置了限流削峰模型，了解用户访问限流，全局访问限流
动态扩容
有些应用可能在一天的某几个时段请求会非常大，但是其它时段请求会很小的情况，比如做定时抢购等等。假如日常TPS并发在500左右，两台服务器就可以支撑，但是在每日的 18::00 TPS并发猛增到3000，这个时候需要10台服务器才能支撑，有没有一种根据并发量来动态扩容的方案呢？
可以了解弹性容器解决方案，经过大量的线上应用反馈，我们建议以CPU作为核心监控指标。