One doubt about redis, maybe not correct.
For transactions persistence is very important, if we use redis, the transactions may lose persistence property. Event you provide retry mechanism, but how about the redis instance is restarted and memory data get lost? Do you mean that using redis clusters and sync memory data between clusters and assume that clusters is high available? ------------------ ???????? ------------------ ??????: "willem.jiang"<[email protected]>; ????????: 2018??8??16??(??????) ????11:00 ??????: "dev"<[email protected]>; ????: Re: Performance tuning of ServiceComb Saga Pack We cannot guarantee to update the redis and DB at the same time, we can just do the retry in our code. Willem Jiang Twitter: willemjiang Weibo: ????willem On Thu, Aug 16, 2018 at 10:29 AM, fu chengeng <[email protected]> wrote: > Hi Willem > why not just store 'finished transacation' data to db in a async way.can > we guarantee update on both > db and redis are success at same time when the transation is aborted? > ??????: Willem Jiang > ????????: 8??16???????? 09:40 > ????: Re: Performance tuning of ServiceComb Saga Pack > ??????: [email protected] > > > Hi Amos Alpha send response to the Omega once the message is updated into > redis, then we just store the transaction events into the database in async > way (we don't change the states here). Current Redis cluster provides the > persistent storage, it could reduce lot of effort of us. Now we just use > redis as a smaller table for tracking all the unfinished transaction status > to get better performance. If the transaction is aborted, we can updated > the transaction in the DB and Redis at same time, if any of those calls is > failed, I think we just keep trying to update the status. Willem Jiang > Twitter: willemjiang Weibo: ????willem On Wed, Aug 15, 2018 at 10:48 PM, > Zheng Feng wrote: > 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 : > > > > 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 > > > > >
