Kami tidak akan membahas apakah itu lingkungan PHP, JSP atau .NET di sini. Kami melihat masalah dari perspektif arsitektur. Menerapkan bahasa bukanlah masalah. Keuntungan bahasa terletak pada implementasi daripada baik atau buruk. Tidak peduli bahasa apa yang Anda pilih, arsitektur yang harus dihadapi.
1. Pemrosesan data besar -besaran
Seperti yang kita semua tahu, untuk beberapa situs yang relatif kecil, jumlah data tidak terlalu besar. Pilih dan Perbarui dapat menyelesaikan masalah yang kita hadapi. Beban itu sendiri tidak terlalu besar, dan paling banyak beberapa indeks dapat dilakukan. Untuk situs web besar, jumlah data per hari mungkin jutaan. Jika hubungan banyak-ke-banyak yang dirancang dengan buruk tidak bermasalah pada tahap awal, tetapi seiring dengan tumbuhnya pengguna, jumlah data akan tumbuh secara geometris. Pada saat ini, ketika kami memilih dan memperbarui tabel (belum lagi permintaan bersama dari beberapa tabel) biayanya sangat tinggi.
2. Pemrosesan Konsurrensi Data
Pada titik tertentu, CTO 2.0 memiliki pedang Shangfang, yang merupakan cache. Untuk cache, ini juga merupakan masalah besar ketika konkurensi tinggi dan pemrosesan tinggi dilakukan. Di seluruh aplikasi, cache dibagikan secara global. Namun, ketika kami membuat modifikasi, jika dua atau lebih permintaan memerlukan pembaruan untuk cache secara bersamaan, aplikasi akan mati secara langsung. Pada saat ini, diperlukan strategi pemrosesan dan strategi caching data yang baik.
Selain itu, ini adalah masalah kebuntuan basis data. Mungkin kita biasanya tidak merasa bahwa probabilitas kebuntuan yang terjadi dalam konkurensi tinggi sangat tinggi, dan caching disk adalah masalah besar.
3. Masalah penyimpanan file
Untuk beberapa situs yang mendukung pengunggahan file 2.0, ketika kami beruntung bahwa kapasitas hard disk semakin besar dan lebih besar, kami harus mempertimbangkan lebih banyak bagaimana file harus disimpan dan diindeks secara efektif. Solusi umum adalah menyimpan file berdasarkan tanggal dan ketik. Namun, ketika volume file sangat besar, jika hard disk menyimpan 500 g file sepele, maka IO disk adalah masalah besar selama pemeliharaan dan penggunaan. Bahkan jika bandwidth Anda cukup, disk Anda mungkin tidak merespons. Jika mengunggah terlibat saat ini, disk akan dengan mudah berakhir.
Mungkin menggunakan server penyimpanan RAID dan khusus dapat menyelesaikan masalah saat ini, tetapi ada masalah lain yang merupakan masalah akses di berbagai tempat. Mungkin server kami ada di Beijing, mungkin dalam kecepatan akses Yunnan atau Xinteng? Jika didistribusikan, bagaimana seharusnya indeks file dan arsitektur kami direncanakan.
Jadi kita harus mengakui bahwa penyimpanan file adalah masalah yang sangat sulit
4. Pemrosesan Hubungan Data
Kami dapat dengan mudah merencanakan basis data yang sesuai dengan normal ketiga, yang penuh dengan banyak hubungan dan juga dapat menggantikan kolom yang mengidentifikasi dengan GUID. Namun, di era 2.0 di mana banyak hubungan yang dibanjiri, yang normal ketiga adalah yang pertama yang harus ditinggalkan. Kueri sendi multi-meja harus diminimalkan secara efektif.
5. Masalah Pengindeksan Data
Seperti yang kita semua tahu, pengindeksan adalah solusi paling murah dan termudah untuk meningkatkan kueri efisiensi basis data. Namun, dalam hal pembaruan tinggi, biaya pembaruan dan hapus akan tinggi dan tidak terpikirkan. Penulis mengalami situasi di mana dibutuhkan 10 menit untuk menyelesaikan saat memperbarui indeks yang terfokus, jadi untuk situs ini, ini pada dasarnya tidak tertahankan.
Pengindeksan dan pembaruan adalah sepasang musuh alami. Pertanyaan A, D, dan E adalah masalah yang harus kami pertimbangkan saat melakukan arsitektur, dan mungkin juga masalah yang memakan waktu paling banyak.
6. Pemrosesan Terdistribusi
Untuk 2.0 situs web, karena interaktivitasnya yang tinggi, efek yang dicapai oleh CDN pada dasarnya 0, dan konten diperbarui secara real time, yang merupakan pemrosesan reguler kami. Untuk memastikan kecepatan akses di berbagai tempat, kita perlu menghadapi masalah besar, yaitu, bagaimana secara efektif mewujudkan sinkronisasi data dan memperbarui dan mewujudkan komunikasi real-time server di berbagai tempat adalah masalah yang harus dipertimbangkan.
7. Analisis Pro dan Kontra Ajax
Sukses adalah Ajax, kegagalan adalah Ajax, Ajax telah menjadi tren arus utama, dan saya tiba -tiba menemukan pos itu dan didasarkan pada xmlhttp sangat mudah. Klien mendapatkan atau memposting data ke server, dan server kembali setelah menerima permintaan data. Ini adalah permintaan AJAX yang sangat normal. Namun, saat memproses AJAX, jika kami menggunakan alat pengambilan paket, pengembalian dan pemrosesan data jelas sekilas. Untuk beberapa permintaan AJAX dengan volume komputasi yang tinggi, kami dapat membangun kontraktor, yang dapat dengan mudah membunuh server web.
8. Analisis Keamanan Data
Untuk protokol HTTP, paket data ditransmisikan dalam teks biasa. Mungkin kita dapat mengatakan bahwa kita dapat menggunakan enkripsi, tetapi untuk masalah G, proses enkripsi mungkin teks biasa (misalnya, QQ yang kita tahu dapat dengan mudah menilai enkripsi dan secara efektif menulis metode enkripsi dan dekripsi seperti itu). Ketika lalu lintas situs Anda tidak terlalu besar, tidak ada yang akan peduli dengan Anda, tetapi ketika lalu lintas Anda muncul, plug-in yang disebut dan apa yang disebut pengiriman massal akan mengikuti satu demi satu (petunjuk dapat dilihat dari pengiriman massal di awal QQ). Mungkin kita bisa mengatakan banyak bahwa kita dapat menggunakan penilaian tingkat lebih tinggi atau bahkan HTTP untuk mencapai ini. Perhatikan bahwa ketika Anda melakukan pemrosesan ini, Anda akan membayar banyak biaya database, IO dan CPU. Untuk beberapa siaran massal, pada dasarnya tidak mungkin. Penulis sudah dapat mewujudkan penerbitan massal untuk ruang Baidu dan ruang QQ. Tidak sulit bagi semua orang untuk mencobanya.
9. Masalah Sinkronisasi Data dan Pemrosesan Cluster
Ketika salah satu layanan data kami kewalahan, kami perlu melakukan beban dan kelompok berbasis database. Ini mungkin masalah yang paling merepotkan. Data didasarkan pada transmisi jaringan. Penundaan data adalah masalah yang mengerikan dan masalah yang tak terhindarkan. Dengan cara ini, kita perlu menggunakan cara lain untuk memastikan interaksi yang efektif dalam beberapa detik atau lebih dari penundaan ini. Misalnya, hashing data, segmentasi, pemrosesan konten dan masalah lainnya.
10. Saluran Berbagi Data dan Tren OpenAPI
OpenAPI telah menjadi tren yang tak terhindarkan, dari Google, Facebook, MySpace ke kampus -kampus di rumah, masalah ini sedang dipertimbangkan. Ini dapat lebih efektif mempertahankan pengguna dan merangsang lebih banyak minat dan memungkinkan lebih banyak orang untuk membantu Anda melakukan pengembangan yang paling efektif. Pada saat ini, untuk platform berbagi data yang efektif, platform data terbuka menjadi cara yang sangat diperlukan. Memastikan keamanan data dan kinerja dengan antarmuka terbuka adalah masalah lain yang harus kita pertimbangkan dengan serius.