Jawaban Donnie (jajak pendapat) mungkin merupakan pilihan terbaik Anda - sederhana dan berhasil. Ini akan mencakup hampir setiap kasus (pencarian PK sederhana sepertinya tidak akan mengganggu kinerja, bahkan di situs yang sangat populer).
Untuk kelengkapan, dan jika Anda ingin menghindari polling, Anda dapat menggunakan model-push . Ada berbagai cara yang dijelaskan dalam artikel Wikipedia. Jika Anda dapat mempertahankan cache tulis (setiap kali Anda memperbarui catatan, Anda memperbarui cache), maka Anda hampir dapat menghilangkan beban basis data.
Namun, jangan gunakan kolom "last_updated" stempel waktu. Pengeditan dalam detik yang sama tidak pernah terdengar. Anda bisa lolos jika Anda menambahkan informasi tambahan (server yang melakukan pembaruan, alamat jarak jauh, port, dll) untuk memastikan bahwa, jika dua permintaan masuk pada detik yang sama, ke server yang sama, Anda dapat mendeteksi perbedaannya. Namun, jika Anda membutuhkan presisi itu, Anda mungkin juga menggunakan bidang revisi unik (tidak harus berupa bilangan bulat yang bertambah, hanya unik dalam masa pakai catatan itu).
Seseorang menyebutkan koneksi persisten - ini akan mengurangi biaya penyiapan kueri polling (setiap koneksi menggunakan sumber daya pada database dan mesin host, tentu saja). Anda akan membiarkan satu koneksi (atau sesedikit mungkin) terbuka sepanjang waktu (atau selama mungkin) dan menggunakannya (dalam kombinasi dengan caching dan memoization, jika diinginkan).
Terakhir, ada pernyataan SQL yang memungkinkan Anda menambahkan kondisi pada UPDATE atau INSERT. SQl saya benar-benar berkarat, tetapi saya pikir ini seperti UPDATE ... WHERE ... . Untuk mencocokkan tingkat perlindungan ini, Anda harus melakukan penguncian baris Anda sendiri sebelum mengirim pembaruan (dan semua penanganan kesalahan dan pembersihan yang mungkin diperlukan). Tidak mungkin Anda membutuhkan ini; Saya hanya menyebutkannya untuk kelengkapan.
Sunting:
Solusi Anda terdengar baik (stempel waktu cache, permintaan polling proxy ke server lain). Satu-satunya perubahan yang saya buat adalah memperbarui cap waktu yang di-cache pada setiap penyimpanan. Ini akan membuat cache lebih segar. Saya juga akan memeriksa stempel waktu langsung dari db saat menyimpan untuk mencegah penyimpanan menyelinap masuk karena data cache basi.
Jika Anda menggunakan APC untuk caching, maka server HTTP kedua tidak masuk akal - Anda harus menjalankannya di mesin yang sama (APC menggunakan memori bersama). Mesin fisik yang sama akan melakukan pekerjaan, tetapi dengan overhead tambahan dari server HTTP kedua. Jika Anda ingin memuat permintaan polling ke server kedua (lightttpd, dalam kasus Anda), maka akan lebih baik untuk mengatur lightttpd di depan Apache pada mesin fisik kedua dan menggunakan server caching bersama (memcache) sehingga server lighttpd dapat membaca cap waktu yang di-cache, dan Apache dapat memperbarui cap waktu yang di-cache. Alasan untuk menempatkan lighttpd di depan Apache adalah, jika sebagian besar permintaan adalah permintaan polling, untuk menghindari penggunaan proses Apache yang lebih berat.
Anda mungkin tidak memerlukan server kedua sama sekali, sungguh. Apache harus dapat menangani permintaan tambahan. Jika tidak bisa, saya akan meninjau kembali konfigurasi Anda (khususnya arahan yang mengontrol berapa banyak proses pekerja yang Anda jalankan dan berapa banyak permintaan yang boleh mereka tangani sebelum dihentikan).
