관심있는것들

why focus on zookeepr 1. N * Servers -> N * Performance? 2. what is api for genral purpose coordinate service? ,raft is library zk works on top of ZAB which is similar to raft replica should never serves(write operation) client because it's data might not be consistent with other , leader can work fine with majority and some replica might not get updated write should be served with leader zookee..

we should avoid split brain 1. client needs to talk to both servers to get some progress (worst idea, worst than single server communication) 2. client can talk to single server to get some progress , but we might have some network issue , each server will hold wrong result and move on majority vote more than half of server should response to get some progress (leader election.. etc) always calc..

state transfer = primary send what ram is storing to backup (replica) replicated state machine = send operation from client not memory , primary and backups are executing operation same time primary fails -> cut-over == client knows it need to send request to backup even with replicated state machine when replica fails and we need to create new replica , we need to use state transfter and send f..

Why is it hard to build BIg Stoarge want performance -> do sharding -> faults(some storage might fail) -> we want tolerance -> so we use replication -> now there can be inconsistency -> we need lots of network talking to achieve consistency -> low performance trade off happens bad replication design want to keep this 2 table identical we haven't made any process that 2 servers are going to handl..

why use Threads I/O Concurrency = using mutiple thread to call remote procedure, each thread will call remote i/o and wait for answer Parallelism Convience = do something in background or periodically with out Threads event driven programming = has single thread and single loop (like nodejs) , cant have parallelism , hard to write sequential programming , Thread chanllenges threads share same me..

https://suhwan.dev/2019/06/09/transaction-isolation-level-and-lock/ Lock으로 이해하는 Transaction의 Isolation Level 개요 내게 transaction의 isolation level은 개발할 때 항상 큰 찝찝함을 남기게 하는 요소였다. row를 읽기만 할 때는 REPEATABLE READ로, row를 삽입 / 수정 / 삭제할 때는 SERIALIZABLE로 isolation level을 지정했지 suhwan.dev 여기에 예시도 많음 Row level lock 가장 기본적인 lock은 테이블의 row마다 걸리는 row-level lock이다. shared lock(S lock) = read대한 lock Exclusive lock(X..