Does it have the risk to lose the data ? If we write the data to the redis and it fails to persistent data just like crashing ?
what is the aof mode of the redis ? Does it guarantee the data consistence ? 2018-08-16 9:28 GMT+08:00 fu chengeng <oliug...@hotmail.com>: > Hi > can we use the write back way to use redis? only write data to redis, > and redis use the aof mode to persistent data. alpha uses an asynchronous > thread to put these 'cold data' to db and delete it from redis. alpha only > read and write with redis. > > > ?取 Outlook for Android<https://aka.ms/ghei36> > > ________________________________ > From: Zheng Feng <zh.f...@gmail.com> > Sent: Wednesday, August 15, 2018 10:48:34 PM > To: dev@servicecomb.apache.org > Subject: Re: Performance tuning of ServiceComb Saga Pack > > Hi Willem, > > It makes sense to use the redis to store the pending transactions (I assume > that you mean these are the "HOT" ones). But we could be very careful to > "write" the transaction status, and it should be stored in the database at > last. So I think we must make sure the transaction status in the redis and > the DB is consist and we SHOULD NOT lose the any status of the transaction. > > How will you use the redis and the database when storing the status of > transaction ? > 1. write to the redis and the redis will sync to the database later. if > failed, rollback the transaction. > 2. both write to the redis and the database. if any of them failed, > rollback the transaction. > > We need the more detail :) > > Amos > > 2018-08-15 8:48 GMT+08:00 Willem Jiang <willem.ji...@gmail.com>: > > > Hi, > > > > With the help of JuZheng[1][2], we managed to deploy the saga-spring-demo > > into K8s and start the Jmeter tests for it. By running the test for a > > while, the DB CPU usage is very high and the response time is up 2~3 > > seconds per call. > > > > It looks like all the event are stored into the database in the same > table > > and never cleaned. > > Now we are thinking use redis to store the hot data (the saga transaction > > which is not closed), and put the cold data (which is used for auditing) > > into database. In this way it could keep the event data smaller and the > > event sanner[4] can just go through the unfinished the Saga transactions > to > > fire the timeout event or the compensation event. > > > > Any thought? > > > > [1]https://github.com/apache/incubator-servicecomb-saga/pull/250 > > [2]https://github.com/apache/incubator-servicecomb-saga/pull/252 > > [3] > > https://github.com/apache/incubator-servicecomb-saga/ > > tree/master/saga-demo/saga-spring-demo > > [4] > > https://github.com/apache/incubator-servicecomb-saga/blob/ > > 44491f1dcbb9353792cb44d0be60946e0e4d7a1a/alpha/alpha-core/ > > src/main/java/org/apache/servicecomb/saga/alpha/core/EventScanner.java > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > >
