ແຜນທີ່ເສັ້ນທາງ Odyssey: ພວກເຮົາຕ້ອງການຫຍັງອີກຈາກຕົວເຊື່ອມຕໍ່. Andrey Borodin (2019)

ໃນບົດລາຍງານຂອງລາວ, Andrey Borodin ຈະບອກທ່ານວ່າພວກເຂົາພິຈາລະນາປະສົບການຂອງຂະຫນາດ PgBouncer ແນວໃດເມື່ອອອກແບບຕົວເຊື່ອມຕໍ່. Odyssey, ຍ້ອນວ່າເຂົາເຈົ້າ rolled ມັນອອກໃນການຜະລິດ. ນອກຈາກນັ້ນ, ພວກເຮົາຈະປຶກສາຫາລືກ່ຽວກັບຫນ້າທີ່ຂອງຕົວດຶງທີ່ພວກເຮົາຢາກເຫັນໃນຮຸ່ນໃຫມ່: ມັນເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາບໍ່ພຽງແຕ່ຕອບສະຫນອງຄວາມຕ້ອງການຂອງພວກເຮົາ, ແຕ່ເພື່ອພັດທະນາຊຸມຊົນຜູ້ໃຊ້. Odyssey.

ວິດີໂອ:

ສະບາຍດີທຸກຄົນ! ຂ້ອຍຊື່ Andrew.

ຢູ່ Yandex, ຂ້ອຍພັດທະນາຖານຂໍ້ມູນແຫຼ່ງເປີດ. ແລະໃນມື້ນີ້ພວກເຮົາມີຫົວຂໍ້ກ່ຽວກັບການເຊື່ອມຕໍ່ pooler ການເຊື່ອມຕໍ່.

ຖ້າທ່ານຮູ້ວິທີໂທຫາການເຊື່ອມຕໍ່ pooler ໃນພາສາລັດເຊຍ, ແລ້ວບອກຂ້ອຍ. ຂ້າພະເຈົ້າກໍ່ຕ້ອງການຊອກຫາຄໍາສັບດ້ານວິຊາການທີ່ດີທີ່ຄວນຈະຖືກສ້າງຕັ້ງຂຶ້ນໃນວັນນະຄະດີດ້ານວິຊາການ.

ຫົວຂໍ້ແມ່ນຂ້ອນຂ້າງສັບສົນ, ເພາະວ່າໃນຫຼາຍໆຖານຂໍ້ມູນ, ຕົວເຊື່ອມຕໍ່ເຊື່ອມຕໍ່ແມ່ນສ້າງຂຶ້ນໃນແລະທ່ານບໍ່ຈໍາເປັນຕ້ອງຮູ້ກ່ຽວກັບມັນ. ແນ່ນອນ, ມີບາງການຕັ້ງຄ່າຢູ່ທົ່ວທຸກແຫ່ງ, ແຕ່ໃນ Postgres ມັນບໍ່ໄດ້ເຮັດວຽກແບບນັ້ນ. ແລະໃນຂະຫນານ (ທີ່ HighLoad ++ 2019) ມີບົດລາຍງານໂດຍ Nikolai Samokhvalov ກ່ຽວກັບການຕັ້ງຄ່າການສອບຖາມໃນ Postgres. ແລະຕາມທີ່ຂ້ອຍເຂົ້າໃຈມັນ, ປະຊາຊົນມາທີ່ນີ້ທີ່ໄດ້ກໍານົດການສອບຖາມຂອງພວກເຂົາຢ່າງສົມບູນ, ແລະເຫຼົ່ານີ້ແມ່ນຜູ້ທີ່ປະເຊີນຫນ້າກັບບັນຫາລະບົບທີ່ຫາຍາກກວ່າທີ່ກ່ຽວຂ້ອງກັບເຄືອຂ່າຍແລະການນໍາໃຊ້ຊັບພະຍາກອນ. ແລະໃນບາງບ່ອນ, ມັນອາດຈະເປັນເລື່ອງຍາກຫຼາຍໃນຄວາມຮູ້ສຶກວ່າບັນຫາບໍ່ຈະແຈ້ງ.

Yandex ມີ Postgres. ການບໍລິການ Yandex ຈໍານວນຫຼາຍອາໄສຢູ່ໃນ Yandex.Cloud. ແລະພວກເຮົາມີຂໍ້ມູນຫຼາຍ petabytes ທີ່ສ້າງຢ່າງຫນ້ອຍຫນຶ່ງລ້ານຄໍາຮ້ອງຂໍຕໍ່ວິນາທີໃນ Postgres.

ແລະພວກເຮົາສະຫນອງກຸ່ມມາດຕະຖານທີ່ຂ້ອນຂ້າງສໍາລັບການບໍລິການທັງຫມົດ - ນີ້ແມ່ນ node ຕົ້ນຕໍຕົ້ນຕໍຂອງ node, ປົກກະຕິສອງ replicas (synchronous ແລະ asynchronous), ສໍາຮອງຂໍ້ມູນ, ຂະຫນາດຂອງຄໍາຮ້ອງຂໍການອ່ານຢູ່ໃນ replica ໄດ້.

ແຕ່ລະ node cluster ແມ່ນ Postgres, ໃນນັ້ນ, ນອກຈາກ Postgres ແລະລະບົບການຕິດຕາມ, ມີການຕິດຕັ້ງ pooler ການເຊື່ອມຕໍ່. pooler ເຊື່ອມຕໍ່ຖືກນໍາໃຊ້ສໍາລັບການຮົ້ວແລະສໍາລັບຈຸດປະສົງຕົ້ນຕໍຂອງຕົນ.

ຈຸດປະສົງຕົ້ນຕໍຂອງການເຊື່ອມຕໍ່ pooler ແມ່ນຫຍັງ?

Postgres ຮັບຮອງເອົາຮູບແບບຂະບວນການໃນເວລາທີ່ເຮັດວຽກກັບຖານຂໍ້ມູນ. ນີ້ຫມາຍຄວາມວ່າການເຊື່ອມຕໍ່ຫນຶ່ງແມ່ນຂະບວນການຫນຶ່ງ, ຫນຶ່ງ Postgres backend. ແລະໃນ backend ນີ້ມີຖານຄວາມຈໍາທີ່ແຕກຕ່າງກັນຫຼາຍ, ເຊິ່ງຂ້ອນຂ້າງແພງທີ່ຈະເຮັດໃຫ້ແຕກຕ່າງກັນສໍາລັບການເຊື່ອມຕໍ່ທີ່ແຕກຕ່າງກັນ.

ນອກຈາກນັ້ນ, ລະຫັດ Postgres ມີ array ທີ່ເອີ້ນວ່າ procArray. ມັນມີຂໍ້ມູນພື້ນຖານກ່ຽວກັບການເຊື່ອມຕໍ່ເຄືອຂ່າຍ. ແລະເກືອບທຸກຂັ້ນຕອນການປະມວນຜົນ procArray ມີຄວາມຊັບຊ້ອນເສັ້ນຊື່; ພວກມັນແລ່ນຜ່ານ array ທັງຫມົດຂອງການເຊື່ອມຕໍ່ເຄືອຂ່າຍ. ມັນເປັນວົງຈອນທີ່ໄວພໍສົມຄວນ, ແຕ່ດ້ວຍການເຊື່ອມຕໍ່ເຄືອຂ່າຍທີ່ເຂົ້າມາຫຼາຍຂຶ້ນ, ສິ່ງຕ່າງໆຈະແພງຂຶ້ນເລັກນ້ອຍ. ແລະໃນເວລາທີ່ສິ່ງທີ່ມີລາຄາແພງກວ່າເລັກນ້ອຍ, ທ່ານສາມາດສິ້ນສຸດການຈ່າຍຄ່າທີ່ສູງຫຼາຍສໍາລັບການເຊື່ອມຕໍ່ເຄືອຂ່າຍຫຼາຍ.

ມີ 3 ວິທີການທີ່ເປັນໄປໄດ້:

• ໃນດ້ານຄໍາຮ້ອງສະຫມັກ.
• ໃນດ້ານຖານຂໍ້ມູນ.
• ແລະລະຫວ່າງ, ນັ້ນແມ່ນ, ທຸກປະເພດຂອງການປະສົມ.

ແຕ່ຫນ້າເສຍດາຍ, ການກໍ່ສ້າງໃນ pooler ກໍາລັງພັດທະນາ. ຫມູ່ເພື່ອນຂອງພວກເຮົາຢູ່ PostgreSQL Professional ເຮັດສິ່ງນີ້ສ່ວນໃຫຍ່. ໃນເວລາທີ່ມັນຈະປາກົດແມ່ນຍາກທີ່ຈະຄາດຄະເນ. ແລະໃນຄວາມເປັນຈິງ, ພວກເຮົາມີສອງວິທີແກ້ໄຂສໍາລັບສະຖາປະນິກທີ່ຈະເລືອກເອົາຈາກ. ເຫຼົ່ານີ້ແມ່ນສະນຸກເກີຂ້າງແອັບພລິເຄຊັນແລະພຣັອກຊີສະນຸກເກີ.

ສະນຸກເກີຂ້າງແອັບພລິເຄຊັນແມ່ນວິທີທີ່ງ່າຍທີ່ສຸດ. ແລະເກືອບທຸກໄດເວີລູກຄ້າສະຫນອງວິທີການ: ນໍາສະເຫນີການເຊື່ອມຕໍ່ຂອງທ່ານໃນລະຫັດຫຼາຍລ້ານການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ.

ບັນຫາທີ່ເກີດຂື້ນແມ່ນວ່າໃນຈຸດໃດຫນຶ່ງທີ່ທ່ານຕ້ອງການທີ່ຈະປັບຂະຫນາດ backend, ທ່ານຕ້ອງການທີ່ຈະນໍາໃຊ້ມັນກັບເຄື່ອງ virtual ຫຼາຍ.

ຫຼັງ​ຈາກ​ນັ້ນ​, ທ່ານ​ຮູ້​ວ່າ​ທ່ານ​ມີ​ຫຼາຍ​ເຂດ​ທີ່​ມີ​ຢູ່​ຫຼາຍ​, ສູນ​ຂໍ້​ມູນ​ຫຼາຍ​. ແລະວິທີການລວມຂອງຝ່າຍລູກຄ້ານໍາໄປສູ່ຕົວເລກທີ່ໃຫຍ່ກວ່າ. ຂະຫນາດໃຫຍ່ແມ່ນປະມານ 10 ເຊື່ອມຕໍ່. ນີ້ແມ່ນຂອບທີ່ສາມາດເຮັດວຽກໄດ້ຕາມປົກກະຕິ.

ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບ proxy poolers, ຫຼັງຈາກນັ້ນມີສອງ poolers ທີ່ສາມາດເຮັດໄດ້ຫຼາຍຢ່າງ. ພວກເຂົາເຈົ້າບໍ່ພຽງແຕ່ poolers. ພວກເຂົາເປັນ poolers + ຟັງຊັນເຢັນຫຼາຍ. ນີ້ Pgpool и Crunchy-Proxy.

ແຕ່ຫນ້າເສຍດາຍ, ບໍ່ແມ່ນທຸກຄົນຕ້ອງການຟັງຊັນເພີ່ມເຕີມນີ້. ແລະມັນນໍາໄປສູ່ຄວາມຈິງທີ່ວ່າ poolers ສະຫນັບສະຫນູນພຽງແຕ່ Session pooling, i.e. ຫນຶ່ງລູກຄ້າຂາເຂົ້າ, ຫນຶ່ງລູກຄ້າຂາອອກກັບຖານຂໍ້ມູນ.

ນີ້ບໍ່ເຫມາະສົມກັບຈຸດປະສົງຂອງພວກເຮົາ, ດັ່ງນັ້ນພວກເຮົາໃຊ້ PgBouncer, ເຊິ່ງປະຕິບັດການລວມທຸລະກໍາ, ເຊັ່ນ: ການເຊື່ອມຕໍ່ເຊີຟເວີຖືກຈັບຄູ່ກັບການເຊື່ອມຕໍ່ລູກຄ້າສໍາລັບໄລຍະເວລາຂອງທຸລະກໍາເທົ່ານັ້ນ.

ແລະໃນວຽກງານຂອງພວກເຮົາ, ນີ້ແມ່ນຄວາມຈິງ. ແຕ່ມີບັນຫາເລັກນ້ອຍ.

ບັນຫາເລີ່ມຕົ້ນໃນເວລາທີ່ທ່ານຕ້ອງການວິນິດໄສເຊດຊັນ, ເພາະວ່າການເຊື່ອມຕໍ່ຂາເຂົ້າທັງຫມົດຂອງທ່ານແມ່ນຢູ່ໃນທ້ອງຖິ່ນ. ທຸກຄົນມາກັບ loopback ແລະ somehow ມັນກາຍເປັນການຍາກທີ່ຈະຕິດຕາມກອງປະຊຸມ.

ແນ່ນອນທ່ານສາມາດນໍາໃຊ້ application_name_add_host. ນີ້ແມ່ນວິທີທາງຂ້າງ Bouncer ເພື່ອເພີ່ມທີ່ຢູ່ IP ໃຫ້ກັບ application_name. ແຕ່ application_name ຖືກກໍານົດໂດຍການເຊື່ອມຕໍ່ເພີ່ມເຕີມ.

ໃນກາຟນີ້, ບ່ອນທີ່ເສັ້ນສີເຫຼືອງແມ່ນການຮ້ອງຂໍທີ່ແທ້ຈິງ, ແລະບ່ອນທີ່ເສັ້ນສີຟ້າແມ່ນການຮ້ອງຂໍທີ່ບິນເຂົ້າໄປໃນຖານຂໍ້ມູນ. ແລະຄວາມແຕກຕ່າງນີ້ແມ່ນແນ່ນອນການຕິດຕັ້ງ application_name, ເຊິ່ງຕ້ອງການພຽງແຕ່ສໍາລັບການຕິດຕາມ, ແຕ່ມັນບໍ່ບໍ່ເສຍຄ່າເລີຍ.

ນອກຈາກນັ້ນ, ໃນ Bouncer ທ່ານບໍ່ສາມາດຈໍາກັດຫນຶ່ງສະນຸກເກີ, i.e. ຈໍານວນການເຊື່ອມຕໍ່ຖານຂໍ້ມູນຕໍ່ຜູ້ໃຊ້ສະເພາະ, ຕໍ່ຖານຂໍ້ມູນສະເພາະ.

ອັນນີ້ນໍາໄປສູ່ຫຍັງ? ທ່ານມີບໍລິການໂຫຼດທີ່ຂຽນໄວ້ໃນ C ++ ແລະບາງບ່ອນຢູ່ໃກ້ກັບບໍລິການຂະຫນາດນ້ອຍໃນ node ທີ່ບໍ່ເຮັດຫຍັງຂີ້ຮ້າຍກັບຖານຂໍ້ມູນ, ແຕ່ໄດເວີຂອງມັນບ້າ. ມັນເປີດການເຊື່ອມຕໍ່ 20 ແລະທຸກສິ່ງທຸກຢ່າງອື່ນຈະລໍຖ້າ. ເຖິງແມ່ນວ່າລະຫັດຂອງທ່ານແມ່ນປົກກະຕິ.

ພວກເຮົາ, ແນ່ນອນ, ຂຽນ patch ຂະຫນາດນ້ອຍສໍາລັບ Bouncer ທີ່ເພີ່ມການຕັ້ງຄ່ານີ້, i.e. ການຈໍາກັດລູກຄ້າໃນສະນຸກເກີ.

ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດສິ່ງນີ້ໃນດ້ານ Postgres, i.e., ຈໍາກັດບົດບາດໃນຖານຂໍ້ມູນໂດຍຈໍານວນການເຊື່ອມຕໍ່.

ແຕ່ຫຼັງຈາກນັ້ນທ່ານສູນເສຍຄວາມສາມາດໃນການເຂົ້າໃຈວ່າເປັນຫຍັງທ່ານບໍ່ມີການເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ. PgBouncer ບໍ່ຖິ້ມຂໍ້ຜິດພາດໃນການເຊື່ອມຕໍ່, ມັນສະເຫມີສົ່ງຄືນຂໍ້ມູນດຽວກັນ. ແລະທ່ານບໍ່ສາມາດເຂົ້າໃຈໄດ້: ບາງທີລະຫັດຜ່ານຂອງທ່ານມີການປ່ຽນແປງ, ບາງທີຖານຂໍ້ມູນພຽງແຕ່ສູນເສຍ, ບາງທີອາດມີບາງຢ່າງຜິດພາດ. ແຕ່ບໍ່ມີການວິນິດໄສ. ຖ້າກອງປະຊຸມບໍ່ສາມາດຖືກສ້າງຕັ້ງຂຶ້ນ, ທ່ານຈະບໍ່ຮູ້ວ່າເປັນຫຍັງມັນຈຶ່ງບໍ່ສາມາດສ້າງຕັ້ງຂຶ້ນໄດ້.

ໃນຈຸດໃດຫນຶ່ງ, ທ່ານເບິ່ງກາຟຄໍາຮ້ອງສະຫມັກແລະເຫັນວ່າຄໍາຮ້ອງສະຫມັກບໍ່ເຮັດວຽກ.

ເບິ່ງຢູ່ເທິງສຸດແລະເຫັນວ່າ Bouncer ແມ່ນເສັ້ນດ່ຽວ. ນີ້ແມ່ນຈຸດປ່ຽນຂອງຊີວິດການບໍລິການ. ທ່ານຮັບຮູ້ວ່າທ່ານກໍາລັງກະກຽມຂະຫນາດຖານຂໍ້ມູນໃນປີແລະເຄິ່ງຫນຶ່ງ, ແລະທ່ານຕ້ອງການຂະຫນາດ pooler.

ພວກເຮົາໄດ້ສະຫຼຸບວ່າພວກເຮົາຕ້ອງການ PgBouncers ຫຼາຍ.

https://lwn.net/Articles/542629/

Bouncer ໄດ້ຖືກ patched ເລັກນ້ອຍ.

ແລະພວກເຂົາໄດ້ເຮັດມັນເພື່ອໃຫ້ Bouncers ຫຼາຍຄົນສາມາດຖືກຍົກຂຶ້ນມາໂດຍການໃຊ້ພອດ TCP ຄືນໃໝ່. ແລະລະບົບປະຕິບັດການຈະໂອນການເຊື່ອມຕໍ່ TCP ທີ່ເຂົ້າມາລະຫວ່າງພວກມັນໂດຍອັດຕະໂນມັດໂດຍໃຊ້ round-robin.

ນີ້ແມ່ນຄວາມໂປ່ງໃສຕໍ່ລູກຄ້າ, ຊຶ່ງຫມາຍຄວາມວ່າມັນເບິ່ງຄືວ່າທ່ານມີ Bouncer ຫນຶ່ງ, ແຕ່ວ່າທ່ານມີ fragmentation ຂອງການເຊື່ອມຕໍ່ທີ່ບໍ່ມີປະໂຫຍດລະຫວ່າງແລ່ນ Bouncers.

ແລະໃນເວລານີ້ທ່ານອາດຈະສັງເກດເຫັນວ່າ 3 Bouncers ແຕ່ລະຄົນກິນເຖິງຫຼັກຂອງພວກເຂົາໂດຍ 100%. ທ່ານຕ້ອງການ Bouncers ບໍ່ຫຼາຍປານໃດ. ເປັນຫຍັງ?

ເພາະວ່າທ່ານມີ TLS. ທ່ານມີການເຊື່ອມຕໍ່ເຂົ້າລະຫັດ. ແລະຖ້າຫາກວ່າທ່ານ benchmark Postgres ມີແລະບໍ່ມີ TLS, ທ່ານຈະພົບເຫັນວ່າຈໍານວນຂອງການເຊື່ອມຕໍ່ສ້າງຕັ້ງຂຶ້ນຫຼຸດລົງເກືອບສອງຄໍາສັ່ງຂອງຂະຫນາດທີ່ມີການເຂົ້າລະຫັດເປີດ, ເນື່ອງຈາກວ່າ TLS handshake ໃຊ້ຊັບພະຍາກອນ CPU.

ແລະຢູ່ເທິງສຸດທ່ານສາມາດເບິ່ງຫນ້າທີ່ cryptographic ຂ້ອນຂ້າງບໍ່ຫຼາຍປານໃດທີ່ຖືກປະຕິບັດໃນເວລາທີ່ມີຄື້ນຂອງການເຊື່ອມຕໍ່ຂາເຂົ້າ. ເນື່ອງຈາກຈຸດຫຼັກຂອງພວກເຮົາສາມາດສະຫຼັບລະຫວ່າງເຂດການມີໃຫ້ໄດ້, ຄື້ນຂອງການເຊື່ອມຕໍ່ຂາເຂົ້າແມ່ນສະຖານະການປົກກະຕິ. ນັ້ນແມ່ນ, ດ້ວຍເຫດຜົນບາງຢ່າງທີ່ປະຖົມເກົ່າບໍ່ສາມາດໃຊ້ໄດ້, ການໂຫຼດທັງຫມົດຖືກສົ່ງໄປຫາສູນຂໍ້ມູນອື່ນ. ພວກເຂົາທຸກຄົນຈະມາທັກທາຍ TLS ໃນເວລາດຽວກັນ.

ແລະການຈັບມື TLS ຈໍານວນຫຼວງຫຼາຍອາດຈະບໍ່ເວົ້າສະບາຍດີກັບ Bouncer, ແຕ່ຈະບີບຄໍຂອງລາວ. ເນື່ອງຈາກການໝົດເວລາ, ຄື້ນຂອງການເຊື່ອມຕໍ່ຂາເຂົ້າອາດຈະກາຍເປັນບໍ່ດຸ່ນດ່ຽງ. ຖ້າທ່ານພະຍາຍາມກັບຄືນສູ່ຖານໂດຍບໍ່ມີການ backoff exponential, ພວກມັນຈະບໍ່ມາອີກເທື່ອຫນຶ່ງແລະອີກເທື່ອຫນຶ່ງໃນຄື້ນທີ່ສອດຄ່ອງກັນ.

ນີ້ແມ່ນຕົວຢ່າງຂອງ 16 PgBouncers ທີ່ໂຫລດ 16 cores ຢູ່ທີ່ 100%.

ພວກເຮົາມາຮອດ cascade PgBouncer. ນີ້ແມ່ນການຕັ້ງຄ່າທີ່ດີທີ່ສຸດທີ່ສາມາດເຮັດໄດ້ໃນການໂຫຼດຂອງພວກເຮົາກັບ Bouncer. Bouncers ພາຍນອກຂອງພວກເຮົາຖືກນໍາໃຊ້ສໍາລັບການຈັບມື TCP, ແລະ Bouncers ພາຍໃນແມ່ນໃຊ້ສໍາລັບການລວມກັນທີ່ແທ້ຈິງ, ເພື່ອບໍ່ໃຫ້ fragment ການເຊື່ອມຕໍ່ພາຍນອກຫຼາຍເກີນໄປ.

ໃນ​ການ​ຕັ້ງ​ຄ່າ​ນີ້, restart ກ້ຽງ​ແມ່ນ​ເປັນ​ໄປ​ໄດ້. ທ່ານສາມາດຣີສະຕາດ 18 Bouncers ທັງໝົດນີ້ເທື່ອລະອັນ. ແຕ່ການຮັກສາການຕັ້ງຄ່າດັ່ງກ່າວແມ່ນຂ້ອນຂ້າງຍາກ. Sysadmins, DevOps, ແລະຜູ້ທີ່ຮັບຜິດຊອບຕົວຈິງສໍາລັບເຄື່ອງແມ່ຂ່າຍນີ້ຈະບໍ່ພໍໃຈກັບການຈັດການນີ້.

ມັນເບິ່ງຄືວ່າການປັບປຸງຂອງພວກເຮົາທັງຫມົດສາມາດຖືກສົ່ງເສີມເປັນແຫຼ່ງເປີດ, ແຕ່ Bouncer ບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນທີ່ດີຫຼາຍ. ຕົວຢ່າງ, ຄວາມສາມາດໃນການດໍາເນີນການ PgBouncers ຫຼາຍຢູ່ໃນພອດຫນຶ່ງແມ່ນຫມັ້ນສັນຍາໃນເດືອນກ່ອນ. ມີການຮ້ອງຂໍດຶງກັບຄຸນນະສົມບັດນີ້ຫຼາຍປີກ່ອນຫນ້ານີ້.

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

ຫຼືອີກໜຶ່ງຕົວຢ່າງ. ໃນ Postgres, ທ່ານສາມາດຍົກເລີກການຮ້ອງຂໍທີ່ກໍາລັງດໍາເນີນໂດຍການສົ່ງຄວາມລັບໄປຫາການເຊື່ອມຕໍ່ທີ່ແຕກຕ່າງກັນໂດຍບໍ່ມີການພິສູດຢືນຢັນທີ່ບໍ່ຈໍາເປັນ. ແຕ່ລູກຄ້າບາງຄົນພຽງແຕ່ສົ່ງການປັບ TCP, i.e. ພວກເຂົາເຈົ້າທໍາລາຍການເຊື່ອມຕໍ່ເຄືອຂ່າຍ. Bouncer ຈະເຮັດແນວໃດ? ລາວຈະບໍ່ເຮັດຫຍັງ. ມັນຈະສືບຕໍ່ປະຕິບັດການຮ້ອງຂໍ. ຖ້າທ່ານໄດ້ຮັບການເຊື່ອມຕໍ່ຈໍານວນຫລາຍທີ່ໄດ້ສ້າງຖານຂໍ້ມູນທີ່ມີການຮ້ອງຂໍຂະຫນາດນ້ອຍ, ຫຼັງຈາກນັ້ນພຽງແຕ່ການຍົກເລີກການເຊື່ອມຕໍ່ຈາກ Bouncer ຈະບໍ່ພຽງພໍ; ທ່ານຍັງຈໍາເປັນຕ້ອງເຮັດສໍາເລັດຄໍາຮ້ອງຂໍເຫຼົ່ານັ້ນທີ່ເຮັດວຽກຢູ່ໃນຖານຂໍ້ມູນ.

ນີ້ໄດ້ຖືກ patched ແລະບັນຫານີ້ຍັງບໍ່ໄດ້ຖືກລວມເຂົ້າກັບ Bouncer ຂອງ upstream.

ແລະດັ່ງນັ້ນພວກເຮົາໄດ້ສະຫຼຸບວ່າພວກເຮົາຕ້ອງການຕົວເຊື່ອມຕໍ່ຂອງພວກເຮົາເອງ, ເຊິ່ງຈະຖືກພັດທະນາ, ແກ້ໄຂ, ເຊິ່ງບັນຫາສາມາດແກ້ໄຂໄດ້ໄວແລະແນ່ນອນ, ຕ້ອງມີຫຼາຍກະທູ້.

ພວກເຮົາຕັ້ງ multithreading ເປັນວຽກງານຕົ້ນຕໍ. ພວກເຮົາຈໍາເປັນຕ້ອງສາມາດຈັດການຄື້ນຂອງການເຊື່ອມຕໍ່ TLS ຂາເຂົ້າໄດ້ດີ.

ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຕ້ອງພັດທະນາຫ້ອງສະຫມຸດແຍກຕ່າງຫາກທີ່ເອີ້ນວ່າ Machinarium, ເຊິ່ງຖືກອອກແບບມາເພື່ອອະທິບາຍສະຖານະເຄື່ອງຂອງການເຊື່ອມຕໍ່ເຄືອຂ່າຍເປັນລະຫັດລໍາດັບ. ຖ້າທ່ານເບິ່ງລະຫັດແຫຼ່ງ libpq, ທ່ານຈະເຫັນບາງການໂທທີ່ສັບສົນທີ່ສາມາດສົ່ງຜົນໄດ້ຮັບໃຫ້ທ່ານແລະເວົ້າວ່າ, "ໂທຫາຂ້ອຍໃນພາຍຫລັງ. ດຽວນີ້ຂ້ອຍມີ IO ດຽວນີ້, ແຕ່ເມື່ອ IO ອອກໄປຂ້ອຍຈະມີການໂຫຼດຢູ່ໃນໂປເຊດເຊີ." ແລະນີ້ແມ່ນໂຄງການຫຼາຍລະດັບ. ການສື່ສານເຄືອຂ່າຍປົກກະຕິແລ້ວແມ່ນອະທິບາຍໂດຍເຄື່ອງຂອງລັດ. ກົດລະບຽບຫຼາຍຢ່າງເຊັ່ນ: "ຖ້າຂ້ອຍໄດ້ຮັບຊຸດຫົວຂອງຂະຫນາດ N, ຕອນນີ້ຂ້ອຍລໍຖ້າ N bytes," "ຖ້າຂ້ອຍສົ່ງແພັກເກັດ SYNC, ຕອນນີ້ຂ້ອຍກໍາລັງລໍຖ້າແພັກເກັດທີ່ມີ metadata ຜົນໄດ້ຮັບ." ຜົນໄດ້ຮັບແມ່ນຂ້ອນຂ້າງຍາກ, ລະຫັດ counterintuitive, ຄືກັບວ່າ maze ໄດ້ຖືກປ່ຽນເປັນການສະແກນເສັ້ນ. ພວກເຮົາເຮັດໃຫ້ມັນເປັນດັ່ງນັ້ນ, ແທນທີ່ຈະເປັນເຄື່ອງຈັກຂອງລັດ, ຜູ້ຂຽນໂປລແກລມອະທິບາຍເສັ້ນທາງຕົ້ນຕໍຂອງການໂຕ້ຕອບໃນຮູບແບບຂອງລະຫັດ imperative ທໍາມະດາ. ມັນເປັນພຽງແຕ່ວ່າໃນລະຫັດທີ່ຈໍາເປັນນີ້, ທ່ານຈໍາເປັນຕ້ອງໃສ່ສະຖານທີ່ບ່ອນທີ່ລໍາດັບການປະຕິບັດຕ້ອງໄດ້ຮັບການຂັດຂວາງໂດຍການລໍຖ້າຂໍ້ມູນຈາກເຄືອຂ່າຍ, ຖ່າຍທອດສະພາບການປະຕິບັດໄປຫາ coroutine ອື່ນ (ຫົວຂໍ້ສີຂຽວ). ວິທີການນີ້ແມ່ນຄ້າຍຄືກັນກັບຄວາມຈິງທີ່ວ່າພວກເຮົາຂຽນເສັ້ນທາງທີ່ຄາດວ່າຈະຫຼາຍທີ່ສຸດໃນ maze ຕິດຕໍ່ກັນ, ແລະຫຼັງຈາກນັ້ນເພີ່ມສາຂາໃສ່ມັນ.

ດັ່ງນັ້ນ, ພວກເຮົາມີກະທູ້ຫນຶ່ງທີ່ TCP ຍອມຮັບແລະ round-robin ຜ່ານການເຊື່ອມຕໍ່ TPC ກັບຄົນງານຫຼາຍຄົນ.

ໃນກໍລະນີນີ້, ການເຊື່ອມຕໍ່ລູກຄ້າແຕ່ລະຄົນສະເຫມີເຮັດວຽກຢູ່ໃນໂປເຊດເຊີດຽວ. ແລະນີ້ອະນຸຍາດໃຫ້ທ່ານເພື່ອເຮັດໃຫ້ມັນ cache-ເປັນມິດ.

ແລະນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ປັບປຸງການເກັບລວບລວມແພັກເກັດຂະຫນາດນ້ອຍເຂົ້າໄປໃນຊຸດຂະຫນາດໃຫຍ່ຫນຶ່ງເພື່ອບັນເທົາລະບົບ TCP stack.

ນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ປັບປຸງການເຮັດທຸລະກໍາໃນລັກສະນະທີ່ Odyssey, ເມື່ອຕັ້ງຄ່າ, ສາມາດສົ່ງ CANCEL ແລະ ROLLBACK ໃນກໍລະນີທີ່ການເຊື່ອມຕໍ່ເຄືອຂ່າຍລົ້ມເຫລວ, i.e. ຖ້າບໍ່ມີໃຜລໍຖ້າຄໍາຮ້ອງຂໍ, Odyssey ຈະບອກຖານຂໍ້ມູນບໍ່ໃຫ້ພະຍາຍາມ. ປະຕິບັດຕາມຄໍາຮ້ອງຂໍທີ່ອາດຈະສູນເສຍຊັບພະຍາກອນອັນລ້ໍາຄ່າ.

ແລະທຸກຄັ້ງທີ່ເປັນໄປໄດ້, ພວກເຮົາຮັກສາການເຊື່ອມຕໍ່ກັບລູກຄ້າດຽວກັນ. ອັນນີ້ຫຼີກເວັ້ນການຕິດຕັ້ງ application_name_add_host ຄືນໃໝ່. ຖ້າເປັນໄປໄດ້, ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງປັບຕົວກໍານົດການເພີ່ມເຕີມທີ່ຈໍາເປັນສໍາລັບການວິນິດໄສ.

ພວກເຮົາເຮັດວຽກຢູ່ໃນຜົນປະໂຫຍດຂອງ Yandex.Cloud. ແລະຖ້າທ່ານໃຊ້ PostgreSQL ທີ່ມີການຄຸ້ມຄອງແລະມີການຕິດຕັ້ງຕົວເຊື່ອມຕໍ່, ທ່ານສາມາດສ້າງການຈໍາລອງແບບມີເຫດຜົນອອກໄປຂ້າງນອກ, i.e., ປ່ອຍໃຫ້ພວກເຮົາ, ຖ້າທ່ານຕ້ອງການ, ໂດຍໃຊ້ການຈໍາລອງແບບມີເຫດຜົນ. Bouncer ຈະບໍ່ປ່ອຍກະແສການຈໍາລອງຢ່າງມີເຫດຜົນຢູ່ນອກ.

ນີ້ແມ່ນຕົວຢ່າງຂອງການຕັ້ງຄ່າ replication ຢ່າງມີເຫດຜົນ.

ນອກຈາກນັ້ນ, ພວກເຮົາມີການສະຫນັບສະຫນູນສໍາລັບການຈໍາລອງທາງດ້ານຮ່າງກາຍພາຍນອກ. ໃນ Cloud, ແນ່ນອນ, ນີ້ແມ່ນເປັນໄປບໍ່ໄດ້, ເພາະວ່າຫຼັງຈາກນັ້ນ cluster ຈະໃຫ້ທ່ານຂໍ້ມູນຫຼາຍເກີນໄປກ່ຽວກັບຕົວມັນເອງ. ແຕ່ໃນການຕິດຕັ້ງຂອງທ່ານ, ຖ້າທ່ານຕ້ອງການການຈໍາລອງທາງດ້ານຮ່າງກາຍໂດຍຜ່ານການເຊື່ອມຕໍ່ໃນ Odyssey, ນີ້ແມ່ນເປັນໄປໄດ້.

Odyssey ມີການຕິດຕາມທີ່ເຂົ້າກັນໄດ້ຢ່າງເຕັມສ່ວນກັບ PgBouncer. ພວກເຮົາມີ console ດຽວກັນທີ່ດໍາເນີນການເກືອບທັງຫມົດຄໍາສັ່ງດຽວກັນ. ຖ້າບາງສິ່ງບາງຢ່າງຂາດຫາຍໄປ, ສົ່ງຄໍາຮ້ອງຂໍດຶງ, ຫຼືຢ່າງຫນ້ອຍມີບັນຫາກ່ຽວກັບ GitHub, ແລະພວກເຮົາຈະເຮັດສໍາເລັດຄໍາສັ່ງທີ່ຈໍາເປັນ. ແຕ່ພວກເຮົາມີຫນ້າທີ່ຕົ້ນຕໍຂອງ PgBouncer console ແລ້ວ.

ແລະ, ແນ່ນອນ, ພວກເຮົາມີຂໍ້ຜິດພາດໃນການສົ່ງຕໍ່. ພວກເຮົາຈະສົ່ງຄືນຂໍ້ຜິດພາດທີ່ຖືກລາຍງານໂດຍຖານຂໍ້ມູນ. ທ່ານຈະໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບວ່າເປັນຫຍັງທ່ານບໍ່ໄດ້ຖືກລວມເຂົ້າໃນຖານຂໍ້ມູນ, ແລະບໍ່ພຽງແຕ່ວ່າທ່ານບໍ່ໄດ້ລວມຢູ່ໃນມັນ.

ຄຸນສົມບັດນີ້ຖືກປິດການນຳໃຊ້ໃນກໍລະນີທີ່ທ່ານຕ້ອງການຄວາມເຂົ້າກັນໄດ້ 100% ກັບ PgBouncer. ພວກ​ເຮົາ​ສາ​ມາດ​ປະ​ຕິ​ບັດ​ແບບ​ດຽວ​ກັນ​ກັບ Bouncer​, ພຽງ​ແຕ່​ຈະ​ຢູ່​ຂ້າງ​ທີ່​ປອດ​ໄພ​.

ການພັດທະນາ

ສອງສາມຄໍາກ່ຽວກັບລະຫັດແຫຼ່ງ Odyssey.

https://github.com/yandex/odyssey/pull/66

ຕົວຢ່າງ, ມີຄໍາສັ່ງ "Pause / Resume". ປົກກະຕິແລ້ວພວກມັນຖືກນໍາໃຊ້ເພື່ອປັບປຸງຖານຂໍ້ມູນ. ຖ້າທ່ານຕ້ອງການອັບເດດ Postgres, ທ່ານສາມາດຢຸດມັນໄວ້ຊົ່ວຄາວໃນຕົວເຊື່ອມຕໍ່, ເຮັດ pg_upgrade, ຈາກນັ້ນສືບຕໍ່. ແລະຈາກຝ່າຍລູກຄ້າມັນຈະເບິ່ງຄືວ່າຖານຂໍ້ມູນພຽງແຕ່ຊ້າລົງ. ຫນ້າທີ່ນີ້ໄດ້ຖືກນໍາມາໃຫ້ພວກເຮົາໂດຍປະຊາຊົນຈາກຊຸມຊົນ. ນາງຍັງບໍ່ໄດ້ frozen ເທື່ອ, ແຕ່ໃນໄວໆນີ້ທຸກສິ່ງທຸກຢ່າງຈະເປັນ. (ແຊ່ແຂງແລ້ວ)

https://github.com/yandex/odyssey/pull/73 - ແຊ່ແຂງແລ້ວ

ນອກຈາກນັ້ນ, ຫນຶ່ງໃນລັກສະນະໃຫມ່ໃນ PgBouncer ແມ່ນການສະຫນັບສະຫນູນ SCRAM Authentication, ເຊິ່ງໄດ້ຖືກນໍາມາໃຫ້ພວກເຮົາໂດຍຜູ້ທີ່ບໍ່ໄດ້ເຮັດວຽກຢູ່ໃນ Yandex.Cloud. ທັງສອງແມ່ນຫນ້າທີ່ສະລັບສັບຊ້ອນແລະສໍາຄັນ.

ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າຢາກບອກທ່ານວ່າ Odyssey ແມ່ນເຮັດມາຈາກຫຍັງ, ໃນກໍລະນີທີ່ທ່ານຕ້ອງການຂຽນລະຫັດເລັກນ້ອຍໃນປັດຈຸບັນ.

ທ່ານມີພື້ນຖານແຫຼ່ງ Odyssey, ເຊິ່ງອີງໃສ່ສອງຫ້ອງສະຫມຸດຕົ້ນຕໍ. ຫໍສະໝຸດ Kiwi ແມ່ນການຈັດຕັ້ງປະຕິບັດໂປຣໂຕຄໍຂໍ້ຄວາມ Postgres. ນັ້ນແມ່ນ, ຂໍ້ຄວາມພື້ນເມືອງ 3 ຂອງ Postgres ແມ່ນຂໍ້ຄວາມມາດຕະຖານທີ່ທາງຫນ້າແລະດ້ານຫລັງສາມາດແລກປ່ຽນໄດ້. ພວກເຂົາເຈົ້າໄດ້ຖືກປະຕິບັດຢູ່ໃນຫ້ອງສະຫມຸດ Kiwi.

ຫ້ອງສະຫມຸດ Machinarium ແມ່ນຫ້ອງສະຫມຸດການປະຕິບັດກະທູ້. ຊິ້ນນ້ອຍໆຂອງ Machinarium ນີ້ຖືກຂຽນເປັນພາສາປະກອບ. ແຕ່ຢ່າຕົກໃຈ, ມີພຽງ 15 ເສັ້ນເທົ່ານັ້ນ.

ຖາປັດຕະຍະ Odyssey. ມີເຄື່ອງຈັກຕົ້ນຕໍທີ່ coroutines ກໍາລັງແລ່ນ. ເຄື່ອງຈັກນີ້ປະຕິບັດການຍອມຮັບການເຊື່ອມຕໍ່ TCP ຂາເຂົ້າແລະແຈກຢາຍໃຫ້ເຂົາເຈົ້າໃນບັນດາພະນັກງານ.

ຕົວຈັດການສໍາລັບລູກຄ້າຫຼາຍໆຄົນສາມາດເຮັດວຽກພາຍໃນຫນຶ່ງຄົນງານ. ກະທູ້ຕົ້ນຕໍຍັງດໍາເນີນການ console ແລະການປຸງແຕ່ງວຽກງານ crone ເພື່ອລຶບການເຊື່ອມຕໍ່ທີ່ບໍ່ຈໍາເປັນໃນສະນຸກເກີ.

Odyssey ຖືກທົດສອບໂດຍໃຊ້ຊຸດທົດສອບ Postgres ມາດຕະຖານ. ພວກເຮົາພຽງແຕ່ດໍາເນີນການຕິດຕັ້ງ-ກວດສອບຜ່ານ Bouncer ແລະຜ່ານ Odyssey, ພວກເຮົາໄດ້ຮັບ null div. ມີການທົດສອບຈໍານວນຫນຶ່ງທີ່ກ່ຽວຂ້ອງກັບການຈັດຮູບແບບວັນທີທີ່ບໍ່ຜ່ານຄືກັນໃນ Bouncer ແລະໃນ Odyssey.

ນອກຈາກນັ້ນ, ມີຜູ້ຂັບຂີ່ຈໍານວນຫຼາຍທີ່ມີການທົດສອບຂອງຕົນເອງ. ແລະພວກເຮົາໃຊ້ການທົດສອບຂອງພວກເຂົາເພື່ອທົດສອບ Odyssey.

ນອກຈາກນັ້ນ, ເນື່ອງຈາກການຕັ້ງຄ່າ cascade ຂອງພວກເຮົາ, ພວກເຮົາຕ້ອງທົດສອບ bundles ຕ່າງໆ: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey ເພື່ອໃຫ້ແນ່ໃຈວ່າຖ້າ Odyssey ສິ້ນສຸດລົງໃນສ່ວນໃດໃນ cascade, ມັນຍັງເຮັດວຽກຢູ່. ດັ່ງທີ່ພວກເຮົາຄາດຫວັງ.

ຫວາຍ

ພວກເຮົາໃຊ້ Odyssey ໃນການຜະລິດ. ແລະມັນຈະບໍ່ຍຸຕິທໍາຖ້າຂ້ອຍເວົ້າວ່າທຸກສິ່ງທຸກຢ່າງພຽງແຕ່ເຮັດວຽກ. ບໍ່, ນັ້ນແມ່ນ, ແມ່ນແລ້ວ, ແຕ່ບໍ່ແມ່ນສະເຫມີໄປ. ຕົວຢ່າງ, ໃນການຜະລິດທຸກສິ່ງທຸກຢ່າງພຽງແຕ່ເຮັດວຽກ, ຫຼັງຈາກນັ້ນຫມູ່ເພື່ອນຂອງພວກເຮົາຈາກ PostgreSQL Professional ມາແລະເວົ້າວ່າພວກເຮົາມີຄວາມຈໍາຮົ່ວໄຫຼ. ພວກ​ເຂົາ​ເຈົ້າ​ແມ່ນ​ແທ້, ພວກ​ເຮົາ​ໄດ້​ແກ້​ໄຂ​ໃຫ້​ເຂົາ​ເຈົ້າ. ແຕ່ວ່າມັນແມ່ນງ່າຍດາຍ.

ຫຼັງຈາກນັ້ນ, ພວກເຮົາຄົ້ນພົບວ່າຕົວເຊື່ອມຕໍ່ມີການເຊື່ອມຕໍ່ TLS ຂາເຂົ້າແລະການເຊື່ອມຕໍ່ TLS ຂາອອກ. ແລະການເຊື່ອມຕໍ່ຕ້ອງການໃບຢັ້ງຢືນລູກຄ້າແລະໃບຢັ້ງຢືນເຊີຟເວີ.

ໃບຢັ້ງຢືນເຊີບເວີ bouncer ແລະ Odyssey ຖືກອ່ານຄືນໂດຍ pcache ຂອງພວກເຂົາ, ແຕ່ໃບຢັ້ງຢືນລູກຄ້າບໍ່ຈໍາເປັນຕ້ອງອ່ານຄືນຈາກ pcache, ເພາະວ່າ Odyssey ທີ່ສາມາດຂະຫຍາຍໄດ້ຂອງພວກເຮົາໃນທີ່ສຸດກໍ່ຈະແລ່ນເຂົ້າໄປໃນລະບົບການອ່ານໃບຢັ້ງຢືນນີ້. ສິ່ງ​ນີ້​ເປັນ​ເລື່ອງ​ແປກ​ໃຈ​ສຳລັບ​ພວກ​ເຮົາ, ເພາະວ່າ​ມັນ​ບໍ່​ໄດ້​ໃຊ້​ເວລາ​ດົນ​ທີ່​ຈະ​ຕ້ານທານ. ໃນຕອນທໍາອິດມັນໄດ້ປັບຂະຫນາດ, ແຕ່ຫຼັງຈາກ 20 ການເຊື່ອມຕໍ່ຂາເຂົ້າພ້ອມໆກັນ, ບັນຫານີ້ສະແດງໃຫ້ເຫັນຕົວຂອງມັນເອງ.

Pluggable Authentication Method ແມ່ນຄວາມສາມາດໃນການກວດສອບຄວາມຖືກຕ້ອງໂດຍໃຊ້ເຄື່ອງມື Lunux ທີ່ມີໃນຕົວ. ໃນ PgBouncer ມັນຖືກປະຕິບັດໃນລັກສະນະທີ່ມີກະທູ້ແຍກຕ່າງຫາກເພື່ອລໍຖ້າຄໍາຕອບຈາກ PAM ແລະມີກະທູ້ PgBouncer ຕົ້ນຕໍທີ່ໃຫ້ບໍລິການການເຊື່ອມຕໍ່ໃນປະຈຸບັນແລະສາມາດຂໍໃຫ້ພວກເຂົາອາໄສຢູ່ໃນກະທູ້ PAM.

ພວກເຮົາບໍ່ໄດ້ປະຕິບັດນີ້ສໍາລັບເຫດຜົນງ່າຍດາຍຫນຶ່ງ. ພວກເຮົາມີກະທູ້ຫຼາຍ. ເປັນຫຍັງພວກເຮົາຕ້ອງການອັນນີ້?

ໃນທີ່ສຸດນີ້ສາມາດສ້າງບັນຫາໃນວ່າຖ້າທ່ານມີການກວດສອບຄວາມຖືກຕ້ອງ PAM ແລະການພິສູດຢືນຢັນທີ່ບໍ່ແມ່ນ PAM, ຄື້ນຂະຫນາດໃຫຍ່ຂອງການກວດສອບ PAM ສາມາດຊັກຊ້າການພິສູດຢືນຢັນທີ່ບໍ່ແມ່ນ PAM ໄດ້ຢ່າງຫຼວງຫຼາຍ. ນີ້ແມ່ນ ໜຶ່ງ ໃນສິ່ງທີ່ພວກເຮົາບໍ່ໄດ້ແກ້ໄຂ. ແຕ່ຖ້າທ່ານຕ້ອງການແກ້ໄຂມັນ, ທ່ານສາມາດເຮັດໄດ້.

rake ອີກອັນຫນຶ່ງແມ່ນວ່າພວກເຮົາມີກະທູ້ຫນຶ່ງທີ່ຍອມຮັບການເຊື່ອມຕໍ່ຂາເຂົ້າທັງຫມົດ. ແລະຫຼັງຈາກນັ້ນເຂົາເຈົ້າໄດ້ຖືກຍົກຍ້າຍໄປສະນຸກເກີຂອງພະນັກງານ, ບ່ອນທີ່ການຈັບມື TLS ຈະເກີດຂຶ້ນ.

ເສັ້ນທາງລຸ່ມ, ຖ້າທ່ານມີຄື້ນທີ່ສອດຄ່ອງກັນຂອງ 20 ການເຊື່ອມຕໍ່ເຄືອຂ່າຍ, ພວກເຂົາທັງຫມົດຈະຖືກຍອມຮັບ. ແລະໃນຝ່າຍລູກຄ້າ libpq ຈະເລີ່ມລາຍງານການຫມົດເວລາ. ໂດຍຄ່າເລີ່ມຕົ້ນມັນເບິ່ງຄືວ່າ 000 ວິນາທີ.

ຖ້າພວກເຂົາທັງຫມົດບໍ່ສາມາດເຂົ້າໄປໃນຖານຂໍ້ມູນໃນເວລາດຽວກັນ, ຫຼັງຈາກນັ້ນພວກເຂົາບໍ່ສາມາດເຂົ້າໄປໃນຖານຂໍ້ມູນໄດ້, ເພາະວ່າທັງຫມົດນີ້ສາມາດຖືກປົກຄຸມດ້ວຍການພະຍາຍາມໃຫມ່ທີ່ບໍ່ແມ່ນ exponential.

ພວກເຮົາສະຫຼຸບໄດ້ວ່າພວກເຮົາໄດ້ຄັດລອກໂຄງການຈາກ PgBouncer ທີ່ນີ້ດ້ວຍຄວາມຈິງທີ່ວ່າພວກເຮົາໄດ້ຂັດຂວາງຈໍານວນການເຊື່ອມຕໍ່ TCP ທີ່ພວກເຮົາຍອມຮັບ.

ຖ້າພວກເຮົາເຫັນວ່າພວກເຮົາຍອມຮັບການເຊື່ອມຕໍ່, ແຕ່ໃນທີ່ສຸດພວກເຂົາບໍ່ມີເວລາຈັບມື, ພວກເຮົາຈັດໃສ່ໃນແຖວເພື່ອບໍ່ໃຫ້ເສຍຊັບພະຍາກອນ CPU. ນີ້ນໍາໄປສູ່ຄວາມຈິງທີ່ວ່າການຈັບມືພ້ອມກັນອາດຈະບໍ່ຖືກປະຕິບັດສໍາລັບການເຊື່ອມຕໍ່ທັງຫມົດທີ່ມາຮອດ. ແຕ່ຢ່າງຫນ້ອຍຜູ້ໃດຜູ້ຫນຶ່ງຈະເຂົ້າໄປໃນຖານຂໍ້ມູນ, ເຖິງແມ່ນວ່າການໂຫຼດແມ່ນຂ້ອນຂ້າງຫນັກ.

ແຜນການ

ເຈົ້າຢາກເຫັນຫຍັງໃນອະນາຄົດໃນ Odyssey? ພວກເຮົາພ້ອມທີ່ຈະພັດທະນາຕົນເອງແລະສິ່ງທີ່ພວກເຮົາຄາດຫວັງຈາກຊຸມຊົນ?

ໃນເດືອນສິງຫາ 2019.

ນີ້ແມ່ນສິ່ງທີ່ແຜນທີ່ເສັ້ນທາງ Odyssey ເບິ່ງຄືວ່າໃນເດືອນສິງຫາ:

• ພວກເຮົາຕ້ອງການການກວດສອບຄວາມຖືກຕ້ອງຂອງ SCRAM ແລະ PAM.
• ພວກເຮົາຕ້ອງການສົ່ງຕໍ່ຄໍາຮ້ອງຂໍການອ່ານເພື່ອສະແຕນບາຍ.
• ຂ້ອຍຕ້ອງການຣີສະຕາດອອນໄລນ໌.
• ແລະຄວາມສາມາດໃນການຢຸດຊົ່ວຄາວໃນເຄື່ອງແມ່ຂ່າຍ.

ເຄິ່ງຫນຶ່ງຂອງແຜນທີ່ເສັ້ນທາງນີ້ໄດ້ຖືກສໍາເລັດ, ແລະບໍ່ແມ່ນໂດຍພວກເຮົາ. ແລະນີ້ແມ່ນດີ. ສະນັ້ນໃຫ້ພິຈາລະນາສິ່ງທີ່ຍັງເຫຼືອແລະເພີ່ມຕື່ມ.

ກ່ຽວກັບການສົ່ງຕໍ່ຄໍາຖາມອ່ານເທົ່ານັ້ນເພື່ອສະແຕນບາຍ? ພວກ​ເຮົາ​ມີ replicas ທີ່​ພຽງ​ແຕ່​ຈະ​ເຮັດ​ໃຫ້​ຄວາມ​ຮ້ອນ​ອາ​ກາດ​ໂດຍ​ບໍ່​ມີ​ການ​ປະ​ຕິ​ບັດ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​. ພວກ​ເຮົາ​ຕ້ອງ​ການ​ໃຫ້​ເຂົາ​ເຈົ້າ​ສະ​ຫນອງ​ການ​ລົ້ມ​ເຫຼວ​ແລະ​ການ​ປ່ຽນ​ແປງ​. ໃນກໍລະນີທີ່ມີບັນຫາຢູ່ໃນສູນຂໍ້ມູນຫນຶ່ງ, ຂ້າພະເຈົ້າຢາກຈະຍຶດເອົາພວກມັນດ້ວຍບາງວຽກທີ່ເປັນປະໂຫຍດ. ເນື່ອງຈາກວ່າພວກເຮົາບໍ່ສາມາດກໍາຫນົດຄ່າໂປເຊດເຊີສູນກາງດຽວກັນ, ຫນ່ວຍຄວາມຈໍາດຽວກັນແຕກຕ່າງກັນ, ເພາະວ່າຖ້າບໍ່ດັ່ງນັ້ນການຈໍາລອງຈະບໍ່ເຮັດວຽກ.

ໃນຫຼັກການ, ໃນ Postgres, ເລີ່ມຕົ້ນຈາກ 10, ມັນເປັນໄປໄດ້ທີ່ຈະລະບຸ session_attrs ເມື່ອເຊື່ອມຕໍ່. ທ່ານສາມາດລາຍຊື່ເຈົ້າພາບຖານຂໍ້ມູນທັງຫມົດໃນການເຊື່ອມຕໍ່ແລະເວົ້າວ່າເປັນຫຍັງເຈົ້າໄປຫາຖານຂໍ້ມູນ: ຂຽນຫຼືອ່ານເທົ່ານັ້ນ. ແລະຜູ້ຂັບຂີ່ເອງຈະເລືອກເອົາເຈົ້າພາບທໍາອິດໃນບັນຊີລາຍຊື່ທີ່ລາວມັກທີ່ສຸດ, ເຊິ່ງປະຕິບັດຕາມຄວາມຕ້ອງການຂອງ session_attrs.

ແຕ່ບັນຫາກັບວິທີການນີ້ແມ່ນວ່າມັນບໍ່ຄວບຄຸມການຈໍາລອງ lag. ທ່ານອາດຈະມີການຈໍາລອງແບບຈໍາລອງບາງຢ່າງທີ່ຊັກຊ້າສໍາລັບໄລຍະເວລາທີ່ບໍ່ສາມາດຍອມຮັບໄດ້ສໍາລັບການບໍລິການຂອງທ່ານ. ເພື່ອໃຫ້ສາມາດປະຕິບັດການສອບຖາມການອ່ານແບບຈໍາລອງແບບເຕັມຮູບແບບ, ພວກເຮົາຈໍາເປັນຕ້ອງສະຫນັບສະຫນູນຄວາມສາມາດຂອງ Odyssey ທີ່ຈະບໍ່ດໍາເນີນການໃນເວລາທີ່ມັນບໍ່ສາມາດອ່ານໄດ້.

Odyssey ຕ້ອງໄປຫາຖານຂໍ້ມູນເປັນໄລຍະໆແລະຂໍໃຫ້ໄລຍະຫ່າງຂອງການຈໍາລອງຈາກຂັ້ນຕົ້ນ. ແລະຖ້າມັນມາຮອດມູນຄ່າຈໍາກັດ, ຢ່າອະນຸຍາດໃຫ້ຄໍາຮ້ອງຂໍໃຫມ່ເຂົ້າໄປໃນຖານຂໍ້ມູນ, ບອກລູກຄ້າວ່າມັນຈໍາເປັນຕ້ອງເລີ່ມຕົ້ນການເຊື່ອມຕໍ່ໃຫມ່ແລະ, ອາດຈະເລືອກເຈົ້າພາບອື່ນເພື່ອປະຕິບັດການຮ້ອງຂໍ. ນີ້ຈະຊ່ວຍໃຫ້ຖານຂໍ້ມູນສາມາດຟື້ນຟູການຈໍາລອງ lag ຢ່າງໄວວາແລະກັບຄືນອີກເທື່ອຫນຶ່ງເພື່ອຕອບສະຫນອງກັບຄໍາຮ້ອງຂໍ.

ມັນເປັນການຍາກທີ່ຈະໃຫ້ເວລາສໍາລັບການປະຕິບັດ, ເພາະວ່າມັນເປັນແຫຼ່ງເປີດ. ແຕ່, ຂ້າພະເຈົ້າຫວັງວ່າ, ບໍ່ແມ່ນ 2,5 ປີຄືກັບເພື່ອນຮ່ວມງານຂອງຂ້ອຍຈາກ PgBouncer. ນີ້ແມ່ນລັກສະນະທີ່ຂ້ອຍຢາກເຫັນໃນ Odyssey.

ໃນຊຸມຊົນ, ປະຊາຊົນຖາມກ່ຽວກັບການສະຫນັບສະຫນູນສໍາລັບຄໍາຖະແຫຼງທີ່ກະກຽມ. ໃນປັດຈຸບັນທ່ານສາມາດສ້າງຄໍາຖະແຫຼງທີ່ກະກຽມໃນສອງວິທີ. ທໍາອິດ, ທ່ານສາມາດປະຕິບັດຄໍາສັ່ງ SQL, ຄື "ກະກຽມ". ເພື່ອເຂົ້າໃຈຄໍາສັ່ງ SQL ນີ້, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຮຽນຮູ້ທີ່ຈະເຂົ້າໃຈ SQL ໃນດ້ານ Bouncer. ນີ້ຈະເປັນການ overkill, ເນື່ອງຈາກວ່າມັນແມ່ນ overkill, ເນື່ອງຈາກວ່າພວກເຮົາຕ້ອງການ parser ທັງຫມົດ. ພວກເຮົາບໍ່ສາມາດວິເຄາະທຸກຄຳສັ່ງ SQL ໄດ້.

ແຕ່ມີຄໍາຖະແຫຼງທີ່ກະກຽມໃນລະດັບຂໍ້ຄວາມກ່ຽວກັບ proto3. ແລະນີ້ແມ່ນສະຖານທີ່ໃນເວລາທີ່ຂໍ້ມູນຂ່າວສານທີ່ຄໍາຖະແຫຼງທີ່ກະກຽມໄດ້ຖືກສ້າງຂື້ນມາໃນຮູບແບບທີ່ມີໂຄງສ້າງ. ແລະພວກເຮົາສາມາດສະຫນັບສະຫນູນຄວາມເຂົ້າໃຈວ່າໃນການເຊື່ອມຕໍ່ເຊີຟເວີບາງຢ່າງລູກຄ້າໄດ້ຂໍໃຫ້ສ້າງຄໍາຖະແຫຼງທີ່ກະກຽມ. ແລະເຖິງແມ່ນວ່າການເຮັດທຸລະກໍາຖືກປິດ, ພວກເຮົາຍັງຕ້ອງຮັກສາການເຊື່ອມຕໍ່ລະຫວ່າງເຄື່ອງແມ່ຂ່າຍແລະລູກຄ້າ.

ແຕ່ໃນທີ່ນີ້ຄວາມແຕກຕ່າງໃນການສົນທະນາເກີດຂື້ນ, ເພາະວ່າບາງຄົນເວົ້າວ່າທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈປະເພດຂອງຄໍາຖະແຫຼງທີ່ກະກຽມທີ່ລູກຄ້າສ້າງແລະແບ່ງປັນການເຊື່ອມຕໍ່ເຊີຟເວີລະຫວ່າງລູກຄ້າທັງຫມົດທີ່ສ້າງການເຊື່ອມຕໍ່ເຄື່ອງແມ່ຂ່າຍນີ້, i.e., ຜູ້ທີ່ສ້າງຄໍາຖະແຫຼງທີ່ກະກຽມດັ່ງກ່າວ.

Andres Freund ກ່າວວ່າຖ້າລູກຄ້າມາຫາທ່ານຜູ້ທີ່ໄດ້ສ້າງຄໍາຖະແຫຼງທີ່ກຽມໄວ້ແລ້ວໃນການເຊື່ອມຕໍ່ເຄື່ອງແມ່ຂ່າຍອື່ນ, ຫຼັງຈາກນັ້ນໃຫ້ສ້າງມັນສໍາລັບລາວ. ແຕ່ມັນເບິ່ງຄືວ່າຜິດພາດເລັກນ້ອຍທີ່ຈະດໍາເນີນການສອບຖາມໃນຖານຂໍ້ມູນແທນທີ່ຈະເປັນລູກຄ້າ, ແຕ່ຈາກທັດສະນະຂອງນັກພັດທະນາຜູ້ທີ່ຂຽນໂປໂຕຄອນສໍາລັບການພົວພັນກັບຖານຂໍ້ມູນ, ມັນຈະສະດວກຖ້າລາວໄດ້ຮັບການເຊື່ອມຕໍ່ເຄືອຂ່າຍທີ່ງ່າຍດາຍ. ມີການສອບຖາມທີ່ກະກຽມໄວ້.

ແລະອີກອັນໜຶ່ງທີ່ເຮົາຕ້ອງປະຕິບັດ. ຕອນນີ້ພວກເຮົາມີການຕິດຕາມທີ່ເຂົ້າກັນໄດ້ກັບ PgBouncer. ພວກເຮົາສາມາດກັບຄືນເວລາປະຕິບັດການສອບຖາມສະເລ່ຍ. ແຕ່ເວລາສະເລ່ຍແມ່ນອຸນຫະພູມສະເລ່ຍໃນໂຮງຫມໍ: ບາງຄົນເຢັນ, ບາງຄົນອົບອຸ່ນ - ໂດຍສະເລ່ຍ, ທຸກຄົນມີສຸຂະພາບດີ. ມັນບໍ່ແມ່ນຄວາມຈິງ.

ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປະຕິບັດການສະຫນັບສະຫນູນສໍາລັບເປີເຊັນ, ເຊິ່ງຈະຊີ້ໃຫ້ເຫັນວ່າມີການສອບຖາມທີ່ຊ້າທີ່ສູນເສຍຊັບພະຍາກອນແລະຈະເຮັດໃຫ້ການກວດສອບສາມາດຍອມຮັບໄດ້ຫຼາຍຂຶ້ນ.

ສິ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນວ່າຂ້ອຍຕ້ອງການເວີຊັນ 1.0 (ຮຸ່ນ 1.1 ໄດ້ຖືກປ່ອຍອອກມາແລ້ວ). ຄວາມຈິງແລ້ວແມ່ນວ່າ Odyssey ໃນປັດຈຸບັນຢູ່ໃນຮຸ່ນ 1.0rc, i.e. ຜູ້ສະຫມັກປ່ອຍ. ແລະບັນຫາທັງຫມົດທີ່ຂ້າພະເຈົ້າໄດ້ລະບຸໄວ້ໄດ້ຖືກແກ້ໄຂດ້ວຍສະບັບດຽວກັນຢ່າງແທ້ຈິງ, ຍົກເວັ້ນສໍາລັບການຮົ່ວໄຫລຂອງຫນ່ວຍຄວາມຈໍາ.

ເວີຊັ່ນ 1.0 ມີຄວາມໝາຍແນວໃດສຳລັບພວກເຮົາ? ພວກເຮົາກໍາລັງເລື່ອນອອກ Odyssey ກັບຖານຂອງພວກເຮົາ. ມັນແລ່ນຢູ່ໃນຖານຂໍ້ມູນຂອງພວກເຮົາແລ້ວ, ແຕ່ເມື່ອມັນມາຮອດຈຸດ 1 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່ານີ້ແມ່ນຮຸ່ນທີ່ປ່ອຍອອກມາແລະນີ້ແມ່ນຮຸ່ນທີ່ສາມາດເອີ້ນວ່າ 000.

ຫຼາຍຄົນໃນຊຸມຊົນໄດ້ຖາມວ່າເວີຊັນ 1.0 ລວມມີການຢຸດຊົ່ວຄາວ ແລະ SCRAM. ແຕ່ນີ້ຈະຫມາຍຄວາມວ່າພວກເຮົາຈະຈໍາເປັນຕ້ອງໄດ້ເປີດຕົວຮຸ່ນຕໍ່ໄປໃນການຜະລິດ, ເພາະວ່າທັງ SCRAM ແລະການຢຸດຊົ່ວຄາວຍັງບໍ່ທັນຖືກຂ້າຕາຍ. ແຕ່, ສ່ວນຫຼາຍອາດຈະ, ບັນຫານີ້ຈະໄດ້ຮັບການແກ້ໄຂຂ້ອນຂ້າງໄວ.

ຂ້ອຍກໍາລັງລໍຖ້າຄໍາຮ້ອງຂໍດຶງຂອງເຈົ້າ. ຂ້ອຍຍັງຢາກໄດ້ຍິນວ່າເຈົ້າມີບັນຫາຫຍັງກັບ Bouncer. ໃຫ້ປຶກສາຫາລືເຂົາເຈົ້າ. ບາງທີພວກເຮົາສາມາດປະຕິບັດບາງຫນ້າທີ່ທີ່ທ່ານຕ້ອງການ.

ນີ້​ແມ່ນ​ຕອນ​ທ້າຍ​ຂອງ​ພາກ​ສ່ວນ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​, ຂ້າ​ພະ​ເຈົ້າ​ຢາກ​ຈະ​ຮັບ​ຟັງ​ທ່ານ​. ຂອບ​ໃຈ!

ຄໍາຖາມຂອງທ່ານ

ຖ້າຂ້ອຍຕັ້ງ application_name ຂອງຂ້ອຍເອງ, ມັນຈະຖືກສົ່ງຕໍ່ຢ່າງຖືກຕ້ອງ, ລວມທັງການເຮັດທຸລະກໍາໃນ Odyssey ບໍ?

Odyssey ຫຼື Bouncer?

ໃນ Odyssey. ໃນ Bouncer ມັນໄດ້ຖືກຖິ້ມ.

ພວກເຮົາຈະເຮັດຊຸດ.

ແລະຖ້າການເຊື່ອມຕໍ່ທີ່ແທ້ຈິງຂອງຂ້ອຍໂດດລົງໃນການເຊື່ອມຕໍ່ອື່ນໆ, ມັນຈະຖືກສົ່ງຕໍ່ບໍ?

ພວກເຮົາຈະເຮັດຊຸດຂອງຕົວກໍານົດການທັງຫມົດທີ່ລະບຸໄວ້ໃນບັນຊີລາຍຊື່. ຂ້ອຍບໍ່ສາມາດບອກໄດ້ວ່າ application_name ຢູ່ໃນລາຍຊື່ນີ້ຫຼືບໍ່. ຂ້ອຍຄິດວ່າຂ້ອຍໄດ້ເຫັນລາວຢູ່ທີ່ນັ້ນ. ພວກເຮົາຈະກໍານົດຕົວກໍານົດການດຽວກັນທັງຫມົດ. ດ້ວຍການຮ້ອງຂໍຫນຶ່ງ, ຊຸດຈະເຮັດທຸກຢ່າງທີ່ຖືກຕິດຕັ້ງໂດຍລູກຄ້າໃນລະຫວ່າງການເລີ່ມຕົ້ນ.

ຂອບໃຈ, Andrey, ສໍາລັບບົດລາຍງານ! ລາຍງານດີ! ຂ້ອຍດີໃຈທີ່ Odyssey ພັດທະນາໄວແລະໄວຂຶ້ນທຸກໆນາທີ. ຂ້ອຍຕ້ອງການສືບຕໍ່ແບບນີ້. ພວກເຮົາໄດ້ຮ້ອງຂໍໃຫ້ທ່ານມີການເຊື່ອມຕໍ່ຂໍ້ມູນຫຼາຍແຫຼ່ງເພື່ອໃຫ້ Odyssey ສາມາດເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນຕ່າງໆພ້ອມໆກັນ, i.e. ເປັນສໍາລອງແມ່ບົດ, ແລະຫຼັງຈາກນັ້ນເຊື່ອມຕໍ່ກັບແມ່ບົດໃຫມ່ໂດຍອັດຕະໂນມັດຫຼັງຈາກລົ້ມເຫລວ.

ແມ່ນແລ້ວ, ເບິ່ງຄືວ່າຂ້ອຍຈື່ການສົນທະນານີ້. ໃນປັດຈຸບັນມີຫຼາຍບ່ອນເກັບມ້ຽນ. ແຕ່ບໍ່ມີການປ່ຽນລະຫວ່າງພວກມັນ. ໃນດ້ານຂອງພວກເຮົາ, ພວກເຮົາຕ້ອງສໍາຫຼວດເຄື່ອງແມ່ຂ່າຍວ່າມັນຍັງມີຊີວິດຢູ່ແລະເຂົ້າໃຈວ່າຄວາມລົ້ມເຫລວໄດ້ເກີດຂື້ນ, ຜູ້ທີ່ຈະໂທຫາ pg_recovery. ຂ້ອຍມີວິທີການເຂົ້າໃຈມາດຕະຖານທີ່ພວກເຮົາບໍ່ໄດ້ມາຫານາຍ. ແລະພວກເຮົາຄວນເຂົ້າໃຈບາງຢ່າງຈາກຄວາມຜິດພາດຫຼືຫຍັງ? ນັ້ນແມ່ນ, ແນວຄວາມຄິດແມ່ນຫນ້າສົນໃຈ, ມັນໄດ້ຖືກປຶກສາຫາລື. ຂຽນຄໍາເຫັນເພີ່ມເຕີມ. ຖ້າເຈົ້າມີຄົນງານທີ່ຮູ້ຈັກ C, ນັ້ນດີຫຼາຍ.

ບັນຫາຂອງການປັບຂະຫນາດໃນທົ່ວ replicas ຍັງເປັນທີ່ສົນໃຈຂອງພວກເຮົາ, ເພາະວ່າພວກເຮົາຕ້ອງການເຮັດໃຫ້ການຮັບຮອງເອົາກຸ່ມ replicated ເປັນງ່າຍດາຍທີ່ເປັນໄປໄດ້ສໍາລັບນັກພັດທະນາຄໍາຮ້ອງສະຫມັກ. ແຕ່ໃນທີ່ນີ້ຂ້າພະເຈົ້າຢາກມີຄໍາເຫັນເພີ່ມເຕີມ, i.e. ແທ້ເຮັດແນວໃດມັນ, ວິທີການເຮັດມັນດີ.

ຄໍາຖາມແມ່ນຍັງກ່ຽວກັບ replicas. ມັນ turns ໃຫ້ ເຫັນ ວ່າ ທ່ານ ມີ ແມ່ ບົດ ແລະ replicas ຫຼາຍ . ແລະມັນເປັນທີ່ຊັດເຈນວ່າພວກເຂົາໄປຫາຕົວແບບຈໍາລອງຫນ້ອຍກວ່າກັບແມ່ບົດສໍາລັບການເຊື່ອມຕໍ່, ເພາະວ່າພວກເຂົາອາດມີຄວາມແຕກຕ່າງ. ທ່ານກ່າວວ່າຄວາມແຕກຕ່າງຂອງຂໍ້ມູນອາດຈະເປັນເຊັ່ນນັ້ນມັນຈະບໍ່ພໍໃຈກັບທຸລະກິດຂອງທ່ານແລະທ່ານຈະບໍ່ໄປບ່ອນນັ້ນຈົນກ່ວາມັນຖືກເຮັດຊ້ໍາອີກ. ໃນເວລາດຽວກັນ, ຖ້າທ່ານບໍ່ໄດ້ໄປບ່ອນນັ້ນເປັນເວລາດົນ, ແລະຫຼັງຈາກນັ້ນເລີ່ມຕົ້ນໄປ, ຫຼັງຈາກນັ້ນຂໍ້ມູນທີ່ຈໍາເປັນຈະບໍ່ສາມາດໃຊ້ໄດ້ທັນທີ. ນັ້ນແມ່ນ, ຖ້າພວກເຮົາໄປຫາແມ່ແບບຢ່າງຕໍ່ເນື່ອງ, ຫຼັງຈາກນັ້ນ, cache ຢູ່ທີ່ນັ້ນອົບອຸ່ນຂຶ້ນ, ແຕ່ໃນແບບຈໍາລອງ, cache ຊ້າເລັກນ້ອຍ.

ແມ່ນ​ມັນ​ເປັນ​ຄວາມ​ຈິງ. pcache ຈະບໍ່ມີບລັອກຂໍ້ມູນທີ່ທ່ານຕ້ອງການ, cache ທີ່ແທ້ຈິງຈະບໍ່ມີຂໍ້ມູນກ່ຽວກັບຕາຕະລາງທີ່ທ່ານຕ້ອງການ, ແຜນການຈະບໍ່ມີການສອບຖາມ parsed, ຈະບໍ່ມີຫຍັງເລີຍ.

ແລະໃນເວລາທີ່ທ່ານມີບາງປະເພດຂອງກຸ່ມ, ແລະທ່ານເພີ່ມ replica ໃຫມ່ຢູ່ທີ່ນັ້ນ, ຫຼັງຈາກນັ້ນໃນຂະນະທີ່ມັນເລີ່ມຕົ້ນ, ທຸກສິ່ງທຸກຢ່າງທີ່ບໍ່ດີຢູ່ໃນມັນ, i.e. ມັນເພີ່ມ cache ຂອງມັນ.

ຂ້ອຍໄດ້ຮັບຄວາມຄິດ. ວິທີການທີ່ຖືກຕ້ອງຈະເປັນການດໍາເນີນການເປັນເປີເຊັນຂະຫນາດນ້ອຍຂອງການສອບຖາມກ່ຽວກັບການ replica ທໍາອິດ, ເຊິ່ງຈະອົບອຸ່ນຂຶ້ນ cache. ເວົ້າປະມານ, ພວກເຮົາມີເງື່ອນໄຂວ່າພວກເຮົາຕ້ອງຊັກຊ້າຢູ່ຫລັງແມ່ແບບບໍ່ເກີນ 10 ວິນາທີ. ແລະເງື່ອນໄຂນີ້ບໍ່ໄດ້ລວມຢູ່ໃນຫນຶ່ງຄື້ນ, ແຕ່ຢ່າງລຽບງ່າຍສໍາລັບລູກຄ້າບາງຄົນ.

ແມ່ນແລ້ວ, ເພີ່ມນ້ໍາຫນັກ.

ນີ້ແມ່ນຄວາມຄິດທີ່ດີ. ແຕ່ທໍາອິດພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປະຕິບັດການປິດນີ້. ກ່ອນອື່ນ ໝົດ ພວກເຮົາຕ້ອງປິດ, ແລະຫຼັງຈາກນັ້ນພວກເຮົາຈະຄິດກ່ຽວກັບວິທີການເປີດ. ນີ້​ແມ່ນ​ຄຸນ​ນະ​ສົມ​ບັດ​ທີ່​ດີ​ທີ່​ຈະ​ເຮັດ​ໃຫ້​ກ້ຽງ​.

Nginx ມີທາງເລືອກນີ້ slowly start ໃນກຸ່ມສໍາລັບເຄື່ອງແມ່ຂ່າຍ. ແລະລາວຄ່ອຍໆເພີ່ມການໂຫຼດ.

ແມ່ນແລ້ວ, ຄວາມຄິດທີ່ດີ, ພວກເຮົາຈະພະຍາຍາມມັນເມື່ອພວກເຮົາເຂົ້າຫາມັນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com