Laravel中Eloquent事件中的Updated和Saved原來不一樣

发表于 2018-09-08

受任于败军之际，奉命于危难之间，尔来二十有一年矣。

當一個新模型初次被儲存，將會觸發 creating 以及 created 事件。如果一個模型已經存在於資料庫而且呼叫了 save 方法，將會觸發 updating 和 updated 事件。然而，在這兩個狀況下，都將會觸發 saving 和 saved 事件。

Laravel 在資料更新的時候會觸發兩個事件：updated 和 saved。單從官方文件的說明，saved 看起來像是一個方便開發者統一管理新增/更新動作的事件，讓重複的程式碼可以不用被寫在兩個地方（created 和 updated），但是其實 saved 和 updated 的觸發時機是不一樣的。

接來看一下 Laravel eloquent 的原始碼。

// 495 行
public function save(array $options = [])
{
    ...
    if ($this->exists) {
        $saved = $this->isDirty() ?
                    $this->performUpdate($query) : true;
    }
    ...
    if ($saved) {
        $this->finishSave($options);
    }
    return $saved;
}
// 552 行
protected function finishSave(array $options)
{
    $this->fireModelEvent('saved', false);
    $this->syncOriginal();
    if (Arr::get($options, 'touch', true)) {
        $this->touchOwners();
    }
}
// 569 行
protected function performUpdate(Builder $query)
{
    ...
    $dirty = $this->getDirty();
    if (count($dirty) > 0) {
        $this->setKeysForSaveQuery($query)->update($dirty);
        $this->fireModelEvent('updated', false);
    }
    return true;
}

應該盡量使用 updated 而不是 saved 來判斷資料是否更新
可以看到在觸發 updated 之前會先做一次 getDirty() 的檢查，其實就是在檢查這次更新的資料是不是真的有改動資料的值；相反的，saved 不管值有沒有改動都會觸發。如果沒注意到這個差別的話，這在實務上其實會造成一些問題。

例如，我們通常會把資料的結果快取起來，以減少對資料庫的查詢次數。因此當資料有變動的時候，就會需要把對應的快取刪除。為了避免有漏刪的部分，會把刪除快取的動作綁定在 eloquent 事件中。認清 updated 和 saved 之後，就會知道這個動作應該是要綁在 updated；若是綁在 saved 上，就會造成多餘的快取動作，增加機器的成本。當快取數量一多，又有用到類似 redis scan 這種較耗時的功能來找出需要刪除的快取時，對於機器的效能影響更大。

使用 updated 也仍會可能有漏網之魚

但是，要注意的是，即使使用了 updated 也不能說完全避免這件事的發生。這時候又要再看一次 Larvel eloquent 的原始碼了。

// 3093 行
public function getDirty()
{
    $dirty = [];
    foreach ($this->attributes as $key => $value) {
        if (! array_key_exists($key, $this->original)) {
            $dirty[$key] = $value;
        } elseif ($value !== $this->original[$key] &&
                             ! $this->originalIsNumericallyEquivalent($key)) {
            $dirty[$key] = $value;
        }
    }
    return $dirty;
}

可以發現 Laravel 判斷值有沒有改動的比較依據來自於，我們一開始 select 出來的欄位，跟這次要變動的欄位。意思就是，如果我們只 select 了 A 欄位出來，但是更新的是 B 欄位時，即使更動後 B 欄位的值跟更動之前一模一樣，Laravel 仍會把此視為資料的值有所改動。

不過這仍在可以接受的範圍之內。畢竟每個更新之前，若要為了拿到所有欄位而又再多查詢一次資料庫，可能會是一件更浪費資源的事情。

https://medium.com/@lynnlin827/laravel-eloquent-%E4%BA%8B%E4%BB%B6%E4%B8%AD%E7%9A%84-updated-%E5%92%8C-saved-%E5%8E%9F%E4%BE%86%E4%B8%8D%E4%B8%80%E6%A8%A3-caa8ef0ddbc

Laravel使用Ajax上传图片

发表于 2018-09-05

You know some birds are not meant to be caged, their feathers are just too bright.

File uploads is one of the most important functions on the internet, and we have bigger files nowadays, which means it’s not enough to have simple input fields – we need AJAX and processing file upload “in the background”. Here I will show you a simple example of that in Laravel 5.

Let’s say, we have a simple form to upload the product and many photos for it.

And we want to upload photos and see upload progress immediately, only then submitting the form. For that we will use a jQuery-File-Upload library.

Step 1. Database structure

Schema::create('products', function (Blueprint $table) {
    $table->increments('id');
    $table->string('name');
    $table->timestamps();
});
Schema::create('product_photos', function (Blueprint $table) {
    $table->increments('id');
    $table->integer('product_id')->unsigned()->nullable();
    $table->foreign('product_id')->references('id')->on('products');
    $table->string('filename');
    $table->timestamps();
});

And then we have two simple models – app/Product.php and app/ProductPhoto.php.

class Product extends Model
{
    protected $fillable = ['name'];
}

class ProductPhoto extends Model
{
    protected $fillable = ['product_id', 'filename'];
    public function product()
    {
        return $this->belongsTo('App\Product');
    }
}

As you can see, field product_photos.product_id is nullable – which means we can upload photos without saving product with them yet. We’ll show later why.

Step 2. Routes and MVC

First, let’s decide our URLs. In routes/web.php we will have this:


Route::get('/', 'UploadController@uploadForm');
Route::post('/upload', 'UploadController@uploadSubmit');
Route::post('/product', 'UploadController@postProduct');

Basically, homepage for the form, then /upload for AJAX file submit, and /product for submitting the whole product with photos.

Then we have app/Http/Controllers/UploadController.php with these methods:


public function uploadForm()
{
    return view('upload_form');
}
public function uploadSubmit(Request $request)
{
    // This method will cover file upload
}
public function postProduct(Request $request)
{
    // This method will cover whole product submit
}

Step 3. Building the form

Our resources/views/upload_form.blade.php will look like this:


<form action="/product" method="post">
    {{ csrf_field() }}
    Product name:
    <br />
    <input type="text" name="name" />
    <br /><br />
    Product photos (can add more than one):
    <br />
    <input type="file" id="fileupload" name="photos[]" data-url="/upload" multiple />
    <br />
    <div id="files_list"></div>
    <p id="loading"></p>
    <input type="hidden" name="file_ids" id="file_ids" value="" />
    <input type="submit" value="Upload" />
</form>

Step 4. Processing the upload and submit

Now, let’s download jQuery-File-Upload library and put its /js contents into our /public/js. And then we can use it like this – in the end of our upload_form.blade.php:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script src="/js/vendor/jquery.ui.widget.js"></script>
<script src="/js/jquery.iframe-transport.js"></script>
<script src="/js/jquery.fileupload.js"></script>
<script>
    $(function () {
        $('#fileupload').fileupload({
            dataType: 'json',
            add: function (e, data) {
                $('#loading').text('Uploading...');
                data.submit();
            },
            done: function (e, data) {
                $.each(data.result.files, function (index, file) {
                    $('<p/>').html(file.name + ' (' + file.size + ' KB)').appendTo($('#files_list'));
                    if ($('#file_ids').val() != '') {
                        $('#file_ids').val($('#file_ids').val() + ',');
                    }
                    $('#file_ids').val($('#file_ids').val() + file.fileID);
                });
                $('#loading').text('');
            }
        });
    });
</script>

To be honest, I’m not a strong front-ender, so the syntax was written according to jQuery-File-Upload library examples. But basically, it works like this:

fileupload() method is attached to input field and takes two important parameters – name=”photos[]” data-url=”/upload”;
Those parameters are passed via AJAX request to /upload URL – meaning UploadController and method uploadSubmit();
uploadSubmit() physically uploads the file, stores information in the database but doesn’t store product_photos.product_id because we don’t have ID yet. After upload it returns JSON with array of file results;

public function uploadSubmit(Request $request)
{
    $photos = [];
    foreach ($request->photos as $photo) {
        $filename = $photo->store('photos');
        $product_photo = ProductPhoto::create([
            'filename' => $filename
        ]);
        $photo_object = new \stdClass();
        $photo_object->name = str_replace('photos/', '',$photo->getClientOriginalName());
        $photo_object->size = round(Storage::size($filename) / 1024, 2);
        $photo_object->fileID = $product_photo->id;
        $photos[] = $photo_object;
    }
    return response()->json(array('files' => $photos), 200);
}

Those results are shown to the user in the file list (filename and size) and also in the hidden field file_ids which stores values from product_photos.id column;

We can upload more files like this, and our files list will grow bigger and bigger. As soon as we hit the main submit – the data will be posted and UploadController method postProduct() will save the data into products DB table, and also assign new product ID to product_photos entries:

public function postProduct(Request $request)
{
    $product = Product::create($request->all());
    ProductPhoto::whereIn('id', explode(",", $request->file_ids))
        ->update(['product_id' => $product->id]);
    return 'Product saved successfully';
}

https://laraveldaily.com/laravel-ajax-file-upload-blueimp-jquery-library/

Laravel集合中的when方法

发表于 2018-09-05

Hope is a good thing and maybe the best of things. And no good thing ever dies.

Starting at v5.4.12, Laravel Collections now includes a when method that allows you to perform conditional actions on the items without breaking the chain.

Like all the other Laravel Collection methods this one can have a lot of use cases but one example that comes to mind is being able to filter based on a query string parameter.

To demonstrate that example, let’s pretend we have a list of hosts from the Laravel News Podcast:

$hosts = [
    ['name' => 'Eric Barnes', 'location' => 'USA', 'is_active' => 0],
    ['name' => 'Jack Fruh', 'location' => 'USA', 'is_active' => 0],
    ['name' => 'Jacob Bennett', 'location' => 'USA', 'is_active' => 1],
    ['name' => 'Michael Dyrynda', 'location' => 'AU', 'is_active' => 1],
];

Previously to filter based on a query string you might do something like this:

$inUsa = collect($hosts)->where('location', 'USA');
if (request('retired')) {
    $inUsa = $inUsa->filter(function($employee){
        return ! $employee['is_active'];
    });
}

With the new when method you can now do this all in one Collection chain:

$inUsa = collect($hosts)
    ->where('location', 'USA')
    ->when(request('retired'), function($collection) {
        return $collection->reject(function($employee){
            return $employee['is_active'];
        });
    });

https://laravel-news.com/laravel-collections-when-method

区块链分币项目

发表于 2018-09-05

我徒然学会了拒绝热闹，却还未透悟真正的冷清

简介

一个使用虚拟货币进行交易的项目，通过小金额的参与，获得大的收益，架构上才用Laravel和Swooole相结合，Socket消息事实推送。

功能点

首页展示

倒计时购买页面

邀请奖励页面

开奖锁定倒计时页面

中奖通知页面

自动充值页面

提现页面

swoole的平滑重启问题

发表于 2018-08-10

年轻时总以为能遇上许许多多的人。而后你就明白，所谓机缘，其实也不过那么几次。

守护进程（daemon）就是一种长期生存的进程，它不受终端的控制，可以在后台运行。其实我们之前也有了解，比如说nginx，fpm等一般都是作为守护进程在后台提供服务。

熟悉linux的同学可能知道，我们可以利用nohup命令让程序在后台跑。swoole官方也为我们提供了配置选项daemonize，默认不启用守护进程，若要开启守护进程，daemonize设置为true即可。

守护进程有优点，必然也存在缺点。我们启用守护进程后，server内所有的标准输出都会被丢弃，这样的话我们也就无法跟踪进程在运行过程中是否异常之类的错误信息了。为方便起见，swoole为我们提供了另一个配置选项log_file，我们可以指定日志路径，这样swoole在运行时就会把所有的标准输出统统记载到该文件内。

信号

我们了解到，swoole是常驻内存的，若想让修改后的代码生效，就必须Ctrl+C，然后再重启server。对于守护进程化的server呢？了解过kill命令的同学要说了，我直接把它干掉，然后终端下再重启，就可以了。

事实上，对于线上繁忙的server，如果你直接把它干掉了，可能某个进程刚好就只处理了一半的数据，对于天天来回倒腾的你来说，面对错乱的数据你不头疼，DBA也想long死你！

这个时候我们就需要考虑如何平滑重启server的问题了。所谓的平滑重启，也叫“热重启”，就是在不影响用户的情况下重启服务，更新内存中已经加载的php程序代码，从而达到对业务逻辑的更新。

swoole为我们提供了平滑重启机制，我们只需要向swoole_server的主进程发送特定的信号，即可完成对server的重启。

那什么是信号呢？

信号是软件中断，每一个信号都有一个名字。通常，信号的名字都以“SIG”开头，比如我们最熟悉的Ctrl+C就是一个名字叫“SIGINT”的信号，意味着“终端中断”。

平滑重启

在swoole中，我们可以向主进程发送各种不同的信号，主进程根据接收到的信号类型做出不同的处理。比如下面这几个

SIGTERM，一种优雅的终止信号，会待进程执行完当前程序之后中断，而不是直接干掉进程
SIGUSR1，将平稳的重启所有的Worker进程
SIGUSR2，将平稳的重启所有的Task进程

如果我们要实现重启server，只需要向主进程发送SIGUSR1信号就好了。

平滑重启的原理是当主进程收到SIGUSR1信号时，主进程就会向一个子进程发送安全退出的信号，所谓的安全退出的意思是主进程并不会直接把Worker进程杀死，而是等这个子进程处理完手上的工作之后，再让其光荣的“退休”，最后再拉起新的子进程（重新载入新的PHP程序代码）。然后再向其他子进程发送“退休”命令，就这样一个接一个的重启所有的子进程。

我们注意到，平滑重启实际上就是让旧的子进程逐个退出并重新创建新的进程。为了在平滑重启时不影响到用户，这就要求进程中不要保存用户相关的状态信息，即业务进程最好是无状态的，避免由于进程退出导致信息丢失。

在swoole中，重启只能针对Worker进程启动之后载入的文件才有效！什么意思呢，就是说只有在onWorkerStart回调之后加载的文件，重启才有意义。在Worker进程启动之前就已经加载到内存中的文件，如果想让它重新生效，还是只能乖乖的关闭server再重启。

我们看个例子看看到底怎么样向主进程发送SIGUSR1信号以便有效重启Worker进程。

<?php
class Test
{
    public function run($data)
    {
        echo $data;
    }
}

在Test::run方法中，我们第一步仅仅是echo输出swoole_server接收到的数据。

当前目录下我们创建一个swoole_server的类NoReload.php

<?php
require_once("Test.php");
class NoReload
{
    private $_serv;
    private $_test;
    /**
     * init
     */
    public function __construct()
    {
        $this->_serv = new Swoole\Server("127.0.0.1", 9501);
        $this->_serv->set([
            'worker_num' => 1,
        ]);
        $this->_serv->on('Receive', [$this, 'onReceive']);
        $this->_test = new Test;
    }
    /**
     * start server
     */
    public function start()
    {
        $this->_serv->start();
    }
    public function onReceive($serv, $fd, $fromId, $data)
    {
        $this->_test->run($data);
    }
}
$noReload = new NoReload;
$noReload->start();

特别提醒：我们在初始化swoole_server的时候的写法是命名空间的写法

1	new Swoole\Server

该种风格的写法等同于下划线写法 ,swoole对这两种风格的写法都支持

1	new swoole_server

此外我们看下server的代码逻辑：类定义之前require_once了Test.php，初始化的时候设置了一个Worker进程，注册了NoReload::onReceive方法为swoole_server的onReceive回调，在onReceive回调内接收到的数据传递给了Test::run方法处理。

接下来我们写一个client脚本测试下运行结果

<?php
$client = new swoole_client(SWOOLE_SOCK_TCP, SWOOLE_SOCK_SYNC);
$client->connect('127.0.0.1', 9501) || exit("connect failed. Error: {$client->errCode}\n");
// 向服务端发送数据
$client -> send("Just a test.\n");
$client->close();

客户端的测试代码也很简单，连接server并向server发一个字符串信息

在server不动的情况下我们修改下Test.php，代码如下

<?php
class Test
{
    public function run($data)
    {
        // echo $data;
        $data = json_decode($data, true);
        if (!is_array($data)) {
            echo "server receive \$data format error.\n";
            return ;
        } 
        var_dump($data);
    }
}

原先echo直接输出，现在我们改了下Test的代码，如果接收到的数据经过json_decode处理后不是数组，就返回一段内容并结束，否则打印receive到的数据

如果这个时候我们不对server进行重启，运行client的结果肯定还是一样的

server端新的代码未生效，如果Test.php新的代码生效了，会在server所在终端输出“server receive $data format error.”，这符合我们的认知。

下面我们通过ps命令查看下左侧server的主进程的pid，然后通过kill命令向该进程发送SIGUSR1信号，看看结果如何

结果发现即使向主进程发送了SIGUSR1信号，但是左侧server终端显示的依然是未生效的php代码，这也是对的，因为我们说过新的程序代码只针对在onWorkerStart回调之后才加载进来的php文件才能生效，我们事例中Test.php是在class定义之前就加载进来了，所以肯定不生效。

我们新建一个Reload.php文件，把server的代码修改如下

<?php
class Reload
{
    private $_serv;
    private $_test;
    /**
     * init
     */
    public function __construct()
    {
        $this->_serv = new Swoole\Server("127.0.0.1", 9501);
        $this->_serv->set([
            'worker_num' => 1,
        ]);
        $this->_serv->on('Receive', [$this, 'onReceive']);
        $this->_serv->on('WorkerStart', [$this, 'onWorkerStart']);
    }
    /**
     * start server
     */
    public function start()
    {
        $this->_serv->start();
    }
    public function onWorkerStart($serv, $workerId)
    {
        require_once("Test.php");
        $this->_test = new Test;
    }
    public function onReceive($serv, $fd, $fromId, $data)
    {
        $this->_test->run($data);
    }
}
$reload = new Reload;
$reload->start();

仔细观察，我们仅仅移除了在类定义之前引入Test.php以及在__construct中new Test的操作。

而是在__construct方法中增加了onWorkerStart回调，并在该回调内引入Test.php并初始化Test类。

Test.php的代码，我们仍然先后用上面的两处代码为例，运行client看下结果

结果我们发现，在给主进程发送SIGUSR1信号之后，Test.php的新代码生效了。这也便实现了热重启的效果。

如此，我们在Test.php中不论如何更新代码，只需要找到主进程的PID，向它发送SIGUSR1信号即可。同理，SIGUSR2信号是只针对Task进程的，后面可以自行测试下。

热重启的效果实现了，现在针对Reload.php的server，让该server进程守护化看看。

$this->_serv->set([   
    'worker_num' => 1,          
    'daemonize' => true,          
    'log_file' => __DIR__ . '/server.log',
]);

具体操作

设置进程名

1
2
3

$http->on('start', function ($server) {
    swoole_set_process_name('yangzie-test');
});

查看

1	netstat -npl\|grep 9501

shell脚本

echo "loading..."
pid=`pidof yangzie-test`
echo $pid
kill -USR1 $pid
echo "loading success"

https://wiki.swoole.com/wiki/page/p-server/reload.html

lnmput@gmail.com

一个记录PHP, Laravel, MySQL, Linux, Redis, ElasticSearch等web开发实践经验的博客

GitHub