Stanislav

Укажите видимость переменной $arr. Например public. И что передается в метод test конкретно?

Нет, конечно. Здесь не уместен статический метод. Вам же в любом случае придется найти пользователя, а уже затем обновить ему рейтинг.

Я не знаю как ваш Users устроен, но в общем и упрощенном случае следует сделать так:

class Users extends Model {
    ...
    protected $id;
    protected $name;
    protected $password;
    ...
    public function getById($id)
    {
        // Т.е. мы возвращаем эту же модель Users, но уже с данными конкретной записи из БД
        return $this->where('id', $id); 
    }

    public function rating()
    {
        // Возвращает модель рейтинга данного пользователя
        // Саму модель рейтинга здесь хардкожу, но в реальности лучше что-то более гибкое придумать
        return RatingModel::where('user_id', $this->id); 
    }

    public function updateRating($rating)
    {
        // обновляем рейтинг данного пользователя
        $this->rating()->update(['rating'=>$rating]);
    }


    ...
}

Таким образом получается гибкая и понятная система. В самом коде используется так:

$user = (new Users)->getById(1);
$user->updateRating(200);

Статику следует использовать тогда, когда это оправданно и необходимо, и когда без неё нельзя.

function allUnique($str) {
    $strUniqueChars = count_chars($str,3); // 3 - режим, возвращается строка без повторений символов
     /* Если строка без повторений по длине равна изначальной
     * значит повторений изначально и не было */
    return strlen($str) === strlen($strUniqueChars);
}

var_dump( allUnique('1234') ); // bool(true)
var_dump( allUnique('41234') ); // bool(false)

PHP docs: count_chars

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите SOLID, DRY, KISS и остальные модные словечки, постарайтесь всё это осознать, или, на крайняк - зазубрить. Всё придет с опытом, изначально все не понимали зачем всё так сложно, но эта сложность обусловлена неисчислимыми литрами слёз и потраченных нервов, всё не просто так.

Судя по всему это тестовое или учебное задание. От вас требовалось отоверинжинирить простую задачу. Давайте попробуем:

Суть задачи - есть файл с определенной структурой хранения данных, структура строковая. Требуется этот файл преобразовать в другую структуру данных и вывести эту структуру в json формате. Задача ясна.

Разобъем задачу на отдельные независимые этапы:
1) Преобразование одной структуры данных (текстового файла) в другую (объект, понятный PHP, к примеру)
2) Преобразование этой структуры данных в Json формат.
Первый вопрос, который может возникнуть - почему сразу не преобразовать в json? Ответ - при расширении системы в будущем - нам понадобится вывести данные в виде массива, или в виде XML, или даже в виде готового файла Excel. Нам будет сложно дополнять логику изначального класса, ничего при этом не сломав и не затронув уже существующий функционал. Также ответом на этот вопрос может являться каждая буква из SOLID принципов, подробнее отвечу дальше, когда буду пояснять за реализацию, см. ниже

Теперь рассмотрим эту задачу с точки зрения ООП, начнем думать не от конкретной реализации, а от интерфейса и абстракции (мы не парсим конкретный файл, мы парсим просто файл, мы не переводим его в конкретное представление json, мы переводим его просто в представление):
Нам понадобится 2 класса - непосредственно класс, читающий файл и преобразующий его в простейший тип данных (например PHP array). Второй класс - преобразователь простейшего типа данных парсера в какой-то определенный тип:

1. LogFileReaded implements/extends FileReaderContract(интерфейс, возможно абстрактный класс, если понадобится предустановленная логика)
   
   Непосредственно наш преобразователь (не забываем, что передавать путь к файлу и все настройки нужно из вне, к примеру, в конструктор. Нельзя, как вы - хардкодить всё внутрь файла, на крайний случай - можно использовать конфигурацию), на ввод получает файл определенного типа с определенной известной структурой, на выходе выдает информацию из файла, преобразованную в базовый тип (массив, в нашем случае). Если нам когда-то понадобится парсить другой тип данных или структура данных будет изменена - мы сможем написать отдельный класс для этой логики, а не рушить целостность уже работающего кода, добавляя туда новую логику. Запомните - нужно стремиться не менять, а дополнять.
   
   
2. JsonPresenter implements/extends DataTypePresenterContract
   
   Абстракция содержит контракт на метод output(), а в конструкторе принимются исходные данные. В конкретной реализации JsonPresenter в output() будет банальный json_encode() (да, это нормально, нет, класс не лишний и нет, json_encode() нельзя пихать в сам парсер) А теперь к вопросу - почему не следует просто запихать это всё в парсер и вместо массива отдать json: в будущем, когда система будет расширяться - нам понадобится представить данные в виде XML - что тогда будем делать - переписывать весь код парсера ради добавления switch case "json" и т.д.? А если что-то сломается во всей системе? А если вариантов представления станет настолько много, что файл будет просто не читаем? А при данном подходе достаточно будет просто написать новый класс XMLPresenter, или даже ExcelPresenter, который на выводе не строку будет выдавать, а целый файл (опустим типизацию output пока)). Также этот класс можно реализовать в виде декоратора (паттерн), да и много еще как.
   
   

В итоге у нас получается вполне сносная и, что важнее - расширяемая(в разумных пределах) архитектура, не забываем прописать класс клиента и определить конкретные реализации в одном месте - можно упороться и дописать сюда контейнер зависимостей.

К примеру: в итоге, если вас уже повысили, и вы вместо парсинга стали заниматься более высшими материями - новому программисту, чтобы дописать логику преобразования данных в Excel не нужно знать как конкретно вы преобразовывали когда-то эти данные в json, ему не нужно дебажить ваш код, ему достаточно посмотреть на интерфейс - отнаследоваться от него и написать свой собственный метод преобразования и дальше использовать его в нужном месте.

P.S. В данной реализации опускаются и упрощаются некоторые моменты для понятности

Сайт не помрет, все будет в порядке, зависит от сервера и кол-ва запросов. Вообще лучше не делать так, как вы описали, если хотите действительно удобную и расширяемую функциональность. В идеале - поставить node.js сервер(в дополнение к тому, на котором стоит PHP) и socket.io / любую другую библиотеку WebSockets. Но если хотите использовать на сервере только PHP и JQuery / нет возможности использовать VDS/VPS - есть более простой вариант - использовать Pusher/PubHub/ любой другой удаленный обработчик сообщений, в таком случае вам ставить дополнительно на сервере ничего не нужно будет (ну кроме небольшой js библиотеки), но и придется дать денюжку, если запросов будет много, тарифы разные у всех.

Можно и на PHP сервер сделать, могу посоветовать удобную библиотеку Ratchet.

SELECT max(id) FROM tablename

<?php

class Dish
{
    protected $ingridients;

    public function addIngridient($ingridient)
    {
        if($ingridient instanceof Ingridient)
            $this->ingridients[] = $ingridient;
        else
            die('error');
    }

    public function showIngridients()
    {
        foreach ($this->ingridients as $ingridient)
        {
            echo 'Ingridient: '.$ingridient->name.'<br>';
        }
    }
}

class Ingridient
{
    public $name;
    public $price;

    public function __construct($name, $price)
    {
        $this->name = $name;
    }
    //Код класса ингридиента
}

$soup = new Dish();

$soup->addIngridient( new Ingridient('water', '1$') );
$soup->addIngridient( new Ingridient('beef', '5$') );
$soup->addIngridient( new Ingridient('salt', '0.1$') );
$soup->showIngridients(); //нет ошибки

$soup->addIngridient('test'); //есть ошибка
$soup->showIngridients();

Я бы использовал простенький скрипт, написанный на c#/c++/java и т.д (на ваш вкус, можно и php в консоли в цикле запустить), который бы работал всё время и выполнял действия по закрытию матча и обработке результатов(к примеру менять значение 'active' матча в БД и дальше обработать бд пользователей, добавив им денег, или забрав). PHP бы использовал по его прямому назначению - запись ставки, добавление администратором матча и т.д. Это вполне обычная практика.

Никак. PHP - серверный язык и выполняет код на сервере. Вам в браузер приходит только результат выполнения ВСЕГО скрипта. Правильный вариант - делать это через клиентский язык (javascript, например). Если нужно только через PHP - то тут нужен также клиентский язык, чтобы отправлял запросы на сервер (ajax). Если вам нужно от и до сделать на PHP - то могу предложить записывать статус в куки и перезагружать каждый раз страницу, интервал придется реализовать через опять-же клиентский язык.

Идеальный вариант: сформировать нужные данные с помощью PHP и передать их в JavaScript код (с помощью json, например, ну либо своим костылем), в котором уже и производить визуальный вывод.