Це відео не доступне.
Перепрошуємо.
Bagaimana Race Condition Terjadi di Database?
Вставка
- Опубліковано 19 сер 2024
- Bagaimana Race Condition Terjadi di Database?
#programmerzamannow #database #racecondition
JOIN PREMIUM : www.youtube.co...
DISCORD PREMIUM : • Post
Donasi :
Saweria : saweria.co/Pro...
Social Media :
Instagram : / programmerzamannow
Facebook : / programmerzamannow
Telegram : t.me/Programme...
UA-cam : / programmerzamannow
Cara kedua di NoSQL itu basically adalah Optimistic Locking biasa jg di terapkan di SQL dan di bnyak cases lebih cocok jg terapin Optimistic Lock,,,biasanya pakai cara additional condition atau row versionning
Sebenernya ada cara lain untuk handling race condition (secara lebih universal) yang berkaitan dengan update database, yaitu pake schema versioning. Cara ini harus nambahin column version (default nya 1). Nah nanti pas waktu melakukan update misal ada 2 request yang masuk bersamaan dan mengacu pada kolom-kolom yang sama kita lakukan query kurang lebih gini
UPDATE table SET column=value, version=version + 1 WHERE user=eko AND version=oldversion;
kita mengupdate column yang ingin diubah dan increment version nya dengan 1 tetapi kondisi version nya yang lama. Sehingga jika request pertama yang dipilih oleh DB maka request kedua akan failed karena version sudah berubah. #JustSharing.
Strategi itu namanya optimistic locking, mirip seperti solusi kedua yg saya bahas
@@ProgrammerZamanNow iya bener kang, optimistic locking update.
Tapi kang, kalo request itu berbarengan kan nanti mereka versionya pasti sama posisinya. Saya pernah coba ini dan pas ditest 2 request itu punya value version yg sama. Nah itu gmana ya?
@@muhammadsalbiyath4212 iya emg gitu cara kerjanya, ada dua versi sama yg masuk. yang pertama duluan ke update (success), yang kedua akan fail karena version udah ga sama lagi (udah di increment dari percobaan yang pertama)
solusi yang bagus bngt nih
Terima kasih.
thanks
Seru nih race condition, Dlu sya coba terapin optimistic locking dan untuk dapat test case nya pake jmeter concurrent request
Mantap, lagi kena masalah ini, eh muncul videonya, makasih banyak kang 🙏
semoga bermanfaat
thx pak, pemahaman baru bagi saya untuk versi nosql nya
Biasanya saya kalo handle race condition pake distributed lock di level service layernya. cuman case race condition ini masih jadi hal yang menurut saya agak susah, terutama di level performance. karena race condition ini harus dihandle dengan cara ngebikin kondisi itu enggak async, tapi sync. karena sync impact nya ke performance. semisal 1 request makan 100ms, timeout 60s. ada concurrent processes sebanyak 601, otomatis data yang ke 601 pasti kena timeout. udah gitu masing masing proses mulai ke 50 keatas udah pasti akan terasa lama, karena prosesnya masih nyangkut nunggu unlocked
Betul, tujuan lock biar data aman, jadi performance dikorbankan
Gabut gabisa tidur malah nonton konten yg isinya daging. Makasih mas eko 😁
Cara lain bisa jg pakai redis-lock, jadi ketika ada user yang ingin melakukan transaction kita cek dulu user-id tersebut sedang di proses atau tidak, kalo key nya exist artinya sedang di proses kalo tidak lock key nya
Keren idenya..
saya biasanya untuk penanganan awal handling by redis, bikin util manggil setNX, 2 request secara bersamaan sebelum masuk database sudah dilarang , hanya 1 yang akan berhasil
Secara global untuk meng-handle Race Condition adalah menggunakan teknik Mutual Exclusion, di mana jika terjadi request secara simultan, hanya ada satu request yang dapat diproses dan request lainnya harus menunggu sampai request pertama tadi selesai. Teknik ini tidak bergantung pada bahasa pemrograman tertentu. Tapi bisa diimplementasikan hampir disemua bahasa pemrograman.
cara melakukan req simultan nya ituo gimana ya ms ? apa kalau dicontoh ini pakai apps dan web secara bersamaan pakai 1 akun ?
Klo preventif nya di level app nya susah bang, misal app nya running on multiple container, beda container beda mutex
Terimakasih bang untuk penjelasannya.
Waah penjelasan yg clear sekali
pak eko bahas pooling utk spring boot yg best practice dong, kadang ada app yg querynya blm optimal, atau kadang bikin nyangkut di pool dll. Paling sering nemu issue HikariPoll - Connection is not available 😅
Semua database punya fungsi untuk menangani race condition, biasanya lock/start/begin -commit-rollback. Tinggal bagaimana kita memanfaatkannya secara benar.
Beberapa saya temui, mereka kesulitan menggunakan "start-commit/rollback" jika melibatkan banyak table.
Bener pada kesulitan make fitur mysql start trnsaction
Mantap pak eko bermanfaat banget ilmunya, baru tahu bisa gitu ternyata
kalau ditempat saya menggunakan skema balance locked dan balance available, dimana ketika proses transaksi akan dilakukan pemindahan balance dari avaibale ke locked
terima kasih pak eko
Mantap Mas, terima kasih wejangannya
Terima kasih ilmunya pak 🙏🙏
Kalo di laravel mudah di tangani dengan Cache Lock
Makasih bang
pak, kalo kita begin with isolation level serialize query selectnya perlu for update juga ga ya?
thanks for answer
Oh jd ini yg namany race condition,, wkwk dulu nge abuse nickname facebook. Jd teknikny sprti itu di tabrakin 2 input. Tujuan abuse nickname. Buat bkin akun hantu. Jdi stiap orng yg mengunjungi akun kita, bkl 404 not found wkwk
nah ini yang yang saya suka overthinking jika web saya banyak sudah usernya.
jika menggunakan trigger apa masih bisa kena masalah race condition ?
wah mantap sekali ini pak eko, saya sempat cari2 juga bahasan seperti ini sebelum2 nya untuk problem di sistem yang saya bikin, tp saya masih bingung sampai saat ini masih sering terjadi miss data tersebut walaupun sudah menggunakan DBTrx , yaa meskipun lebih jarang dari yang sebelum2 nya, permasalah awal saya karena memang bugs di coding nya karena ada proses integrasi ke 3rd party, dan akhirnya benar2 saya pisahkan proses nya, namun entah kenapa masih aja suka terjadi 2-3 kali, apakah ada yang mengalami hal yang sama jg?
RC di golang tinggal pasangin mutex
Bang, gimana cara handle transactional request.. untuk microservice. Best practice mekanisme untuk nge rollback ke setiap service
SAGA Patterns
Bagus
Barusan aplikasi gue kena kondisi seperti ini, akhirnya saldo jebol, untung masih bisa terdeteksi
Permisi pak mau tanya. Apakah fitur like seperti instagram juga termasuk race condition? Terimakasih semoga dijawab
Nice
Kasusnya kaya saya persis ini waktu pake salah 1 e-wallet pesen double order food tapi saldo masih blm kepotong persis bgt kaya race condition, tapi kayanya skrg udah diupdate sama developnya, jadi begitu mau double order, yang 1 langsung ke update(saldo langsung terpotong).
anda kurang beruntung
@@ProgrammerZamanNow adalagi gak Pak Echo cara lainnya biar bisa dapat gratisan cuma2 😊😅
definisinya double order tuh gimana ya Mas ? masih pemula maaf.
apakah kita perlu Handling Race Condition di semua data atau hanya untuk yang critical saja (seperti saldo, point, dll)?
bagusnya di semua hal, tapi kalo sulit, di hal-hal yang sangat penting
Untuk kasus NoSQL, misal kasus begini:
Eko saldo 1000
transaksi:
A -> 700
B -> 100
C -> 800
Kalau dengan WHERE saldo 1000 nanti transaksi B fail kan ya, yang seharusnya sukses karena saldo masih sisa.
kira-kira gmn ya?
Thanks
mungkin where jika saldo > nilai_transaksi
anggap urutannya A, B, dan C, otomatis B dan C fail, karena saldo udah tidak 1000 lagi
@@ProgrammerZamanNow Tapi transaksi B secara nominal harusnya success kan ya mas, karena nilai transaksinya masih dibawah saldo.
betul, karena B < saldo = 300
@@user-ji6sb1bt9r mungkin bisa retry cek saldo lagi mas, kalau saldo masih bisa dideduct coba set ulang, kalau saldo tidak mencukupi baru kirim error ke user
ACID principles
Kurang paham yang dateng 3 request berbarengan, emang web server bakal ngehandle 3 request itu bareng2 bukan selesain satu2?
kalau dari Compiler Bahasa Pemrograman umumnya single thread, tapi karena Web Server lah yang ngejalanin dengan multi thread sampai batas kemampuan baik hardware atau software tersebut, dan itu masuk akal apalagi untuk server dengan user yang ribuan hingga jutaan, kalau di set pakai single thread doang jadinya nanti delay antrian.
gini mungkin mas maksdnya, dateng 3 request trx . nah request itu ada 3 tahap
1. cek harga
2. validasi saldo apakah cukup atau tidak.
3. update saldo.
nah kecolongannya adalah ketika proses update saldo belum selesai . request lain udah masuk di validasi, yang mana saldo belum selesai diupdate . jadi bisa kecolongn. yang saya bingung justru gimana caranya melakukan 3 request secara bersamaan . haha .. kalau salah maaf ya ..
aku pernah pentest di ewallet beli gpc 1jt cuma bayar 20k pake metode race condition di burp turbo intruder
🔥
berarti saldomu minimal 1jt 20k bg? biar bisa dapat 2 gpc harga 1 jt
untuk penangan locking buat no SQL setahu saya itu namanya optimistic locking,saya mau bertanya apakah boleh juga pak menerapkan optimistic locking pada relational database, dan apakah secara performa sama saja dengan menggunakan row level locking (select for update)+ db trx ?
boleh banget, bisa optimistic locking bisa dimana aja
@@ProgrammerZamanNow thx info pak 🙏
@@ProgrammerZamanNow kalo pake optimistic locking bisa kena deadlock ga pak?
mau tanya mas klw misalkan pake relational terus pke transactional dan di lock, apakah ketika ada proses lain yg select ke table yg sama dia jadi ikut nunggu juga? klw misalkan iya nnti proses yg lain jadi ikut antri dan bisa nyebabin aplikasi jdi lebih lambat response-nya. Bener gtu ga ?
Entahlah, klo di nosql kita bisa get saldo terakhir baru validasi, dan di update...
bang tanya nih, kalo misal ini katakan lah saldonya cukup yaa untuk 3 transaksi tadi dan 3 transaksi tadi jalan barengan. apabila nanti diupdate saldonya pakek query jumlah saldo terakhir, berarti yg mana transaki pertama berhasil dan transaksi kedua dan ketiga gagal juga yaa?
Kang mau tanya, klo kita pakai arsitektur microservices berbasis API apakah bisa melakukan transaction locking? Atau apakah harus menggunakan basis event driven?
dari dulu sempet kepikiran begini sih, ternyata istilahnya ini dan cara menanganinya begitu. Kalo sistem flashsale di marketplace itu pake ini juga ya?
harusnya iya ya, kalau gak pake locking amsyong iphone kuotanya 10 tapi yang berhasil checkout 1000 orang 😁
harusnya iya ya, kalau gak pake locking amsyong iphone kuotanya 10 tapi yang berhasil checkout 1000 orang 😁
Mas, untuk saldo itu memang bagusnya disimpen di field ya mas? Soalnya saya ngitung saldo manual, select sum income - expense
Apa dampaknya kalo misalkan saya terus menggunakan metode itu dalam hal saldo?
kalo transaksinya udah ratusa ribu kali gimana?
@@ProgrammerZamanNow nah itu kurang tahu mas, apakah database nya akan semakin lambat saat query select sum(debit)-sum(kredit)?
Kalau kecil cukup pakai materialized view kalau engine database nya support (Oracle, PostgreSQL, dll) dan di scheduled refresh. Kalau besar diwarehousekan dulu via ETL.
Ada kasus untuk firebase realtime dan firestore ?
.
Pak izin bertanya.. itu lock for update mengunci semua database ? Jadi kalo user pertama lagi nerapin lock for update, user yang kedua bisa query select ke database gak ? Apa harus nunggu user pertama selesai melakukan operasi lock for update ?
logic simple tapi mahal...
pake SELECT FOR UPDATE gimana mas?
udah saya ajarkan di kelas MySQL
race condition gini apakah bisa disolve dengan event-driven architecture?
jadi tiap ada transaksi / permintaan checkout, kita insert ke tabel transaction, tapi tandai sebagai "belum beres checkout", lalu publish event untuk lakukan update saldo sebanyak +/- nilai transaksi, kalau berhasil, baru tandai transaksinya "beres checkout"
kyknya pake event driven pun masih bisa bro kena race
pakai event driven masih bisa kena dan karena saya sndri mengalami
kalau pakai queue seperti kafka untuk handle race condition apakah bisa kang?
Bagaimana cara menentukan fields seperti saldo pada contoh ini apakah field itu adalah data yang akan di update( data yang bergerak) atau ada kriteria tersendiri? Makasih
biasanya data yang bergerak nya
Berarti ini implementasi nya sama juga untuk stok gitu ya bang?
betul
GELOOO daging
kalo aku biasanya di postgres, pake decrement
update table set saldo = saldo - 1000 where user_id = 1
terus di combine sama constraint check di db 'saldo > 0'
bisa juga kan ya temen temen? ato tetep ada bolongnya?
Masuk akal juga..
Keren..
tetep bolong bg kalo saldonya ada 100k, tetep masuk kualifikasi saldo > 0
kalau db slave laging apa kalau pakai locking db itu bisa ya mas? Atau harus ada cara lain?
Mas mau tanya lagi, kalo cara nanganin transaksi yang pending gimana?
Misalkan kita API ke aplikasi aplikasi B (misal Payment Gateway), dan di kita dicatat sebagai saldo. Kita ga tahu aplikasi B akan mengirimkan status berhasil atau gagal. Dan kadang kalo transaksi expired si aplikasi B nya ga ngirim status apapun
mungkin bisa dihandler dari aplikasi a sendiri, misal expired dari b itu 30 menit. Jadi dari aplikasi a kalau ngga dapet feedback dari aplikasi b lebih dari 30 menit bakal otomatis update status jadi expired
Bagaimana jika locking nya menggunakan redis pak? apakah bisa juga?
bantu jawab, bisa. saya biasanya lockingnya pakai distribtued lock punya Redis
Ahha gue punya ide jahat 🗿
link a boss
ini apa sama dengan deadlock ya? apa beda?
berbeda.
race condition ini efeknya inconsistency data
solusinya: pakai transaction / lock
tapi transaction / lock dapat menyebabkan deadlock.
biasanya aplikasi yg trafficnya besar yg mengalami deadlock.
Pas banget, lg nemuin bug ini kmaren. Di production pula wkwk. Cuman untuk data stok barang.
sorry oot, itu app yg dipake gambar apa ya namanya?
canva bang, pilih template papan tulis
Terima kasih.