---
title: "IX. Απορριψιμότητα"
source: Twelve-Factor App
source_url: https://github.com/heroku/12factor
licence: MIT
domain: engineering
subdomain: 12factor
date_added: 2026-04-25
---

## IX. Απορριψιμότητα
### Μεγιστοποίηση ευρωστίας της εφαρμογής μέσω γρήγορης εκκίνησης και κομψού τερματισμού

**Οι [διεργασίες](./processes) της εφαρμογής δώδεκα παραγόντων είναι *απορρίψιμες* (*disposable*), δηλαδή μπορούν να εκκινηθούν και να τερματιστούν μέσα σε μια στιγμή.**  Αυτο διευκολύνει τη γρήγορη ελαστική κλιμάκωση, τη γοργή ανάπτυξη του [κώδικα της εφαρμογής](./codebase) ή τις αλλαγές στις [παραμέτρους](./config), και την ευρωστία των αναπτύξεων της εφαρμογής στην παραγωγή.

Οι διεργασίες θα πρέπει να προσπαθούν να **ελαχιστοποιούν τον χρόνο εκκίνησης**.  Ιδανικά, μια διεργασία παίρνει μερικά δευτερόλεπτα απο τη στιγμή της εντολής εκκίνησης μέχρι τη στιγμή που είναι σηκωμένη και έτοιμη να λάβει αιτήσεις ή εργασίες.  Ο σύντομος χρόνος εκκίνησης παρέχει περισσότερη ευκινησία στην διαδικασία [έκδοσης](./build-release-run) και κλιμάκωσης προς τα πάνω, και βοηθά την ευρωστία, επειδή ο διαχειριστής διεργασιών μπορεί πιο εύκολα να μετακινήσει διεργασίες σε νέα φυσικά μηχανήματα όταν χρειαστεί.

Οι διεργασίες **τερματίζουν κομψά όταν λάβουν το σήμα [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** από τον διαχειριστή διεργασιών.  Για μια διεργασία ιστού (web process), ο κομψός τερματισμός επιτυγχάνεται με το να πάυει να ακούει τη θύρα εξυπηρέτησης (αρνούμενη έτσι νέες αιτήσεις), επιτρέποντας σε τρέχουσες αιτήσεις να ολοκληρωθούν, και έπειτα να κάνει έξοδο.  Σε αυτό το μοντέλο εννοείται πως οι αιτήσεις HTTP είναι σύντομες (όχι παραπάνω από μερικά δευτερόλεπτα), ή στην περίπτωση μακράς δειγματοληψίας (long polling), ο πελάτης (client) θα πρέπει να προσπαθήσει απρόσκοπτα να επανασυνδεθεί όταν η σύνδεση χαθεί.

Για μια διεργασία εργάτη (worker process), ο κομψός τερματισμός επιτυγχάνεται με το να επιστρέφει την τρέχουσα εργασία πίσω στην ουρά εργασιών.  Για παράδειγμα, στο [RabbitMQ](http://www.rabbitmq.com/) ο εργάτης μπορεί να στείλει ένα [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack), στο [Beanstalkd](https://beanstalkd.github.io), η εργασία επιστρέφεται στην ουρά αυτόματα όποτε ένας εργάτης αποσυνδέεται.  Συστήματα βασισμένα σε κλείδωμα (lock-based systems) όπως το [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) πρέπει να σιγουρευτούν ότι απελευθέρωσαν το κλείδωμα από την εγγραφή της εργασίας.  Σε αυτό το μοντέλο εννοείται πως όλες οι εργασίες είναι [επανεισδόχιμες (reentrant)](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29), το οποίο τυπικά επιτυγχάνεται με το να περιέχονται τα αποτελέσματα της εργασίας σε μια συναλλαγή (transaction), ή να είναι η λειτουργία [ταυτοδύναμη (idempotent)](http://en.wikipedia.org/wiki/Idempotence).

Οι διεργασίες θα πρέπει επίσης να είναι **εύρωστες απέναντι στον ξαφνικό θάνατο**, στην περίπτωση αστοχίας του υποκείμενου υλικού.  Καθόσον αυτό είναι ένα πολύ πιο σπάνιο φαινόμενο από ένα κομψό τερματισμό μέσω `SIGTERM`, μπορεί παρολαυτά να συμβεί.  Η συνιστώμενη προσέγγιση είναι η χρήση ενός εύρωστου διαχειριστή ουρών, όπως το Beanstalkd, ο οποίος επιστρέφει τις εργασίες πίσω στην ουρά όταν οι πελάτες αποσυνδεθούν ή λήξει ο χρόνος τους.  Σε κάθε περίπτωση, μια εφαρμογή δώδεκα παραγόντων είναι δομημένη έτσι ώστε να διαχειρίζεται απρόβλεπτους, μη κομψούς τερματισμούς.  Η [σχεδίαση Crash-only](http://lwn.net/Articles/191059/) πάει αυτή την έννοια στην [λογική της κατάληξη](http://docs.couchdb.org/en/latest/intro/overview.html).
