Good day! Need to write a script for sending php. There were a number of questions.

1) When you click on the send button, it will be sent to all customers. I will take a database of customers, run through the cycle and send each one. Is this true?

2) Hosting says that you can send 500 emails per hour, how to put a delay on PHP, that I can send 500 emails, then wait an hour and continue to send?

3) What other rules should be considered when creating a distribution module?

Closed due to the fact that it is necessary to reformulate the question so that it was possible to give an objectively correct answer to the participants Visman , aleksandr barakin , user194374, cheops , Streletz Aug 13 '16 at 9:53 .

The question gives rise to endless debates and discussions based not on knowledge, but on opinions. To get an answer, rephrase your question so that it can be given an unambiguously correct answer, or delete the question altogether. If the question can be reformulated according to the rules set out in the certificate , edit it .

    4 answers 4

    Mailing through the database is not a good decision ... This is an extra load on the base, and therefore a drop in performance, no timeouts for the task (you need to write your crutch), no extensibility, etc. In fact, sending through the database you just write your own handwritten queue at the relational storage, but why write a bicycle when it is already written? :)

    The correct solution is to use a message queue (tasks). They are designed to do the following tasks:

    • deferred processing of user data;
    • transfer of statistics;
    • smoothing the load on a relatively slow system;
    • performing periodic tasks.

    Advantages of this solution:

    • Sending letters is universal from any component of the system, even if it is a registration form or your newsletter. Imagine how cool, you have one interface to send, and you just send the task from anywhere without going to connect the library to send letters.
    • Extensibility - you can add absolutely any distribution channel by simply adding a field type (sms, call, letter, Russian post) and supporting it in the handlers.
    • The time to add a task is always instant for the client adding the message to the queue.
    • The ability to speed up mailing just by adding a few more Workers
    • Reliability - added messages to the queue will not be lost (if so configured), and the task will be considered completed only when the script says that everything is ok. To protect yourself from spoiling the queue daemon, you can deploy a cluster.
    • Relatively fast integration into architecture

    You have a Publisher publishing a message to the queue that you need to send a letter to such and such addressee, with such a text, then there are consyumers (workers) who take these tasks from the queue and send letters to customers. If the cosumer fell, could not send, it simply returns the task to the queue back and it will be taken by another consumer who will try to send it.

    In terms of architecture, I think we figured out, then we will move on to how to get around the restriction on hosting and send letters. If you want to send large volumes, then you can use the service of sending emails with an API, for example, Mailgun , which allows you to send 10,000 emails per month for free, although it is possible that this is still not enough for you ..

    There are services that are engaged in purely mailing - for example, unisender - even then you can not write anything , but simply upload your base of emails there and send them letters.

    To limit the number of transmitted messages, use some kind of storage to store the number. You can create a table in the database and write with an atomic operation to it how many letters were sent in the current hour and stop sending when the interval is exceeded. You can add a case, stating that if the limit is over in the main delivery channel, we send it via the secondary one.

    I would recommend that you switch from a regular hosting to a VPS for solving such problems, due to the possibility of your own administration and the absence of restrictions on sending emails.

    • How to create such a queue with php - 5f0f5
    • one
      @ 5f0f5048ff Easy, for example, you can use RabbitMQ, and the php-amqp driver :) - Firepro

    1) Make the “Send” button and make a page with statistics viewing - which will indicate the number of sent messages and the “Send more” button and send further messages manually.

    2) Set the number of records to be selected in the sample from the database - in your case, this is 500 (unless of course some other messages are sent). And for 500, choose and use the offset in the sample for the following “stocks”.

    3) Check that the mail () function returns to you and either write somewhere or just make sure that the messages go away and interrupt sending if there are several errors in a row.

      1. When you click on the "Send" button, record all messages in a separate table with the status NEW
      2. Write a console script that will send messages that will be taken from the table in which the messages were recorded above. Upon successful sending, change the status of the message to 'OK ", if the error is' ERROR'. When updating the record, the update date should change to count the sent messages per hour.
      3. Run the console script on the crown, get a list of messages. SQL query, you can get the number of messages sent in the last hour. Based on this number, you can determine how many messages you can send. You need to understand whether a message that could not be sent falls within the limit of 500 per hour. Check email for validity before sending.

        Colleagues have already given some good advice on organizing the mailing on their own. But I would advise using ready-made mail sending services. In addition to convenient interfaces, they have a lot of settings and additional features such as delivery tracking, automatic recording of blues, etc.

        A good overview of the services is here: https://habrahabr.ru/post/280634/

        Accordingly, your distribution module is only required to implement the client side of the API. As a rule, you can call synchronously, unless the manual says otherwise. If the place is critical, then make calls deferred or send packs as new letters arrive.