Você precisa do histórico de pontuação? Se não precisa, vai ter só contador de pontos, provavelmente na tabela de usuários (ou no registro do usuário, se for um noSQL).
Se precisar, sugiro uma tabela de registro da pontuação e um "cache" do somatório para ser consultado de forma rápida. A atualização desse cache seria em tempo real e haveria uma rotina de auto-manutenção para atualizar periodicamente o valor. Há muita coisa envolvida nesse tipo de técnica e não vou entrar em detalhes sem saber se é necessário porque a explicação seria longa e eu estou no celular :)
Dê mais detalhes aí. A priori parece simples, na verdade.
Agora fez sentido :)
Obviamente você não vai enviar o evento de "passei um segundo no chat" para os usuários, somente os "joins" e os "parts". O resto é calculado no client.
Como você estará usando socket, você já terá um evento de "saiu do chat" (dependendo do método de conexão, há um delay relativamente grande até a detecção de conexão fechada, então você vai ter que subtrair alguns segundos ou exigir determinados tipos de conexão).
Assim somente os eventos de mensagem e de "like" vão ter broadcast (com a pontuação corrente e o timestamp, para atualizar o ponto de sincronia dos clients, como forma de auto-manutenção), e somente para os usuários "visíveis" (a sala atual, talvez?).
Um bom serviço de socket suporta milhões de mensagens por segundo. O limite fica na conexão do client, não no socket. Considerando isso, para melhorar mais a performance, você pode fazer esses broadcasts periodicamente e não assim que os eventos ocorrem, ou enviar o broadcast num mesmo pacote que vai uma nova mensagem recebida no chat. Assim você teria as trocas de pacotes reduzidas a um mínimo enquanto mantém o ritmo de atualização super constante (dá pra manter os updates com menos de um segundo de atraso).
Diego, obrigado meu caro.
É noSQL (MongoDB).
Não é necessário o histórico, mas preciso que toda atualização na
pontuação do usuário (seja ela causada pelo próprio usuário, por um
usuário terceiro ou pelo segundo que se passou), precisa refletir no
lado do cliente.
Eu criei uma forma, mas ela pode explodir em pedaços o banco de dados:
a cada evento, eu faço um increment na pontuação atual do usuário em
questão (com uma atomic operation), pego então o valor atualizado
final e envio de volta ao usuário em questão.
Se estes eventos de atualização de pontos forem gerados somente nas
trocas de mensagens, ok (pois eu já estou salvando as mensagens no
banco). Mas e a atualização a cada segundo? Se eu tiver 300 pessoas
conectadas, são 300 interações com o banco de dados.
Ele vai explodir!
On Aug 21, 8:34 pm, diego nunes <dnu...@gmail.com> wrote:
> Você precisa do histórico de pontuação? Se não precisa, vai ter só
> contador de pontos, provavelmente na tabela de usuários (ou no registro do
> usuário, se for um noSQL).
> Se precisar, sugiro uma tabela de registro da pontuação e um "cache" do
> somatório para ser consultado de forma rápida. A atualização desse cache
> seria em tempo real e haveria uma rotina de auto-manutenção para atualizar
> periodicamente o valor. Há muita coisa envolvida nesse tipo de técnica e
> não vou entrar em detalhes sem saber se é necessário porque a explicação
> seria longa e eu estou no celular :)
>
> Dê mais detalhes aí. A priori parece simples, na verdade.
> On Aug 21, 2012 7:24 PM, "Filipe" <fili...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Pessoal, o cenário é o seguinte: Express, Socket.io e MongoDB.
>
> > Construí um sistema de chat onde o usuário é remunerado com pontos da
> > seguinte forma:
> > - Ganha 1 ponto a cada segundo que ele passa conectado
> > - Ganha 1 ponto a cada mensagem que ele envia ao chat
> > - Ganha 1 ponto, caso um outro usuário "curta" a mensagem dele.
>
> > Seja qual for a forma como ele ganha este ponto, o client side do
> > usuário precisa ter a resposta em tempo-real dos atuais pontos.
>
> > Como vocês resolveriam esta charada sem abarrotar o banco de dados? :)
>
> > (nao procuro código, apenas a lógica ou conceito)
Mongo, redis, zero mq, socket io e session.