Thank you !
середа, 17 серпня 2016 р. 11:10:13 UTC+3 користувач Tal Pressman написав:
>
> Hi,
>
> Our system isn't in production yet, but the current design is:
>
> - The entire system will run on an Akka cluster (with sharding).
> - "Old" entities are passivated after a certain inactivity period. At
> any given point we expect to have several million live entities.
> - The expected number of commands("transactions") per entity is small
> - 90% will have just a handful of commands, but some can have hundreds.
> - Backend is Cassandra.
>
> Tal
>
>
> On Wednesday, August 17, 2016 at 9:55:30 AM UTC+3, Evgeny Shepelyuk wrote:
>>
>> Hi, thanks for info.
>>
>> May you share some info about your system:
>> - how many actors do you have per JVM
>> - how many transactions are kept in memory per actor
>> - what backend do you use for journal
>>
>> середа, 17 серпня 2016 р. 09:38:12 UTC+3 користувач Tal Pressman написав:
>>>
>>> Hi,
>>>
>>> We have something similar to the in one of our systems, and the way we
>>> did it is to include the list of processed transactions (IDs) as part of
>>> the actor state. In places where it isn't feasible to keep all transactions
>>> in memory, you can use a bloom filter (if you don't require 100% accuracy),
>>> or you will have to use some "external" method to keep track of the
>>> duplicates (DB, some service to check for duplicates, etc.)
>>>
>>> HTH,
>>> Tal
>>>
>>>
>>> On Tuesday, August 16, 2016 at 4:06:06 PM UTC+3, Evgeny Shepelyuk wrote:
>>>>
>>>> I am trying to design a system where an AKKA actor represents smth
>>>> similar to simple banking account or counter
>>>> Each account has a list of transactions that are events generated by
>>>> incoming commands change its state (basically add/remove funds).
>>>> One of my requirement is that system should track if incoming
>>>> transaction was already processed by certain account.
>>>>
>>>> It that case account actor
>>>> 1. should not change state again
>>>> 2. should warn some external system about duplicated transaction.
>>>>
>>>> We expect fairly large number of transactions per account. e.g 10000
>>>> per day.
>>>>
>>>> My first intention was to use akka-persistence to implement event
>>>> sourcing pattern
>>>>
>>>> On incoming command
>>>> - check if command was already processed, (by querying journal or
>>>> checking in memory list)
>>>> - if command was not processed - creating transaction and store it to
>>>> account journal
>>>> - additional put transaction into in-memory list
>>>> - if command with such ID was already processed, then do not generate
>>>> new transaction, and notify someone
>>>>
>>>> But after reading about journals and possible backends (kafka or
>>>> cassandra, since we need it distributed) I consider that maybe
>>>> akka-persistence is not applicable at all for my goals.
>>>> One of assumption is to use event-sourcing only for balance update and
>>>> create snapshots from time to time and use direct DB access outside
>>>> akka-persistence to check for duplicated transactions.
>>>>
>>>> What do you suggest ?
>>>>
>>>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
