馒头的技术博客

基本概念
我们可以用一个简单的例子来说明依赖注入的概念

下面的代码中有一个 Database 的类，它需要一个适配器来与数据库交互。我们在构造函数里实例化了适配器，从而产生了耦合。这会使测试变得很困难，而且 Database 类和适配器耦合的很紧密。

<?php
namespace Database;

class Database
{
    protected $adapter;

    public function __construct()
    {
        $this->adapter = new MySqlAdapter;
    }
}

class MysqlAdapter {}

这段代码可以用依赖注入重构，从而解耦

<?php
namespace Database;

class Database
{
    protected $adapter;

    public function __construct(MySqlAdapter $adapter)
    {
        $this->adapter = $adapter;
    }
}

class MysqlAdapter {}

现在，我们以参数的形式向 Database 类传递其依赖的对象，而不是让它自己产生所依赖的对象。我们甚至可以创建一个方法（method），让这个方法可以接受依赖对象作为参数并在内部设置依赖关系，或者，如果 $adapter 属性本身是 public 的，我们可以直接给它赋值。

复杂的问题
如果你曾经了解过依赖注入，那么你可能见过 “控制反转”(Inversion of Control) 或者 “依赖反转准则”(Dependency Inversion Principle)这种说法。这些是依赖注入能解决的更复杂的问题。

控制反转
顾名思义，一个系统通过组织控制和对象的完全分离来实现”控制反转”。对于依赖注入，这就意味着通过在系统的其他地方控制和实例化依赖对象，从而实现了解耦。

一些 PHP 框架很早以前就已经实现控制反转了，但是问题是，应该反转哪部分以及到什么程度？比如， MVC 框架通常会提供超类或者基本的控制器类以便其他控制器可以通过继承来获得相应的依赖。这就是控制反转的例子，但是这种方法是直接移除了依赖而不是减轻了依赖。

依赖注入允许我们通过按需注入的方式更加优雅地解决这个问题，完全不需要任何耦合。

依赖反转准则
依赖反转准则是面向对象设计准则 S.O.L.I.D 中的 “D” ,倡导 “依赖于抽象而不是具体”。简单来说就是依赖应该是接口/约定或者抽象类，而不是具体的实现。我们能很容易重构前面的例子，使之遵循这个准则

<?php
namespace Database;

class Database
{
    protected $adapter;

    public function __construct(AdapterInterface $adapter)
    {
        $this->adapter = $adapter;
    }
}

interface AdapterInterface {}

class MysqlAdapter implements AdapterInterface {}

1.opchache 性能加强20%
2.水平分表，减少一半字段，对select count(money) 加强15%，对select * 加强在50%
3.PB级数据，列存sql（比如 select count(money)），建议上polardb。记得忽略索引（where 1=1 或 use index()）。1000万条数据，mysql需要40s,列存数据3秒

1.看一段代码
func main() {

    s1 := [5]int{0, 1, 2, 3, 4}
    s2 := s1
    s2[0] = 999
    fmt.Println(s1)   //[0 1 2 3 4]

    s3 := []int{0, 1, 2, 3, 4}
    s4 := s3
    s4[0] = 999    //[999 1 2 3 4]   s3数组是值类型，s3 切片本身是个引用类型
    fmt.Println(s3)
}

1、TPS是什么意思？
TPS全称是：Transaction Per Second，意思是指每秒事务数。TPS是衡量系统性能的一个非常重要的指标。

人们常常混淆并发量与TPS，它们两者的作用不同。如同一条马路，我们关注点是：有几个车道，以及是否拥挤？并发量对应于车道，而TPS对应于拥挤程度。

在做性能测试的时候，传统方式都是用并发数来衡量系统的性能，一般适用于一些网页站点的首页、H5页面的压测。这是站在客户端的视角。而TPS则直接衡量系统的吞吐能力，应用场景主要是一些动态的接口API，例如登录、提交订单等等。这是站在服务端视角的。

2、TPS和并发量的关系
TPS是每秒事务数，但是事务是要靠用户做出来的，假如1个用户在1秒内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1 ms，那么1个用户在1s内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s，那么1个用户在1s内只能完成1笔事务，要想达到1000 TPS，至少需要1000个用户；因此可以说1个用户可以产生1000 TPS，1000个用户也可以产生1000 TPS，无非是看响应时间快慢。

3、如何获取并发量和TPS
3.1、并发量获取方式：
可选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数，并发用户数可以取10%，例如在半个小时内，使用系统的用户数为10万，那么取10%（即1万）作为并发用户数基本就够了。

3.2、TPS获取方式：
可选取高峰时刻，在一定时间内（如3分钟~10分钟），获取系统总业务量，计算单位时间（秒）内完成的笔数，乘以2~5倍作为峰值的TPS，例如峰值3分钟内处理订单18万笔，平均TPS是1000，峰值TPS可以是2000~5000。

4、如何评价系统的性能
针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能。

5、小结
综上所述，可以得出以下结论：

系统的性能由TPS决定，跟并发用户数没有多大关系。
系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
标签: none