Não use UUID
como PK nas tabelas do seu banco de dados.
type Set struct { | |
list map[int]struct{} //empty structs occupy 0 memory | |
} | |
func (s *Set) Has(v int) bool { | |
_, ok := s.list[v] | |
return ok | |
} |
First of all, please note that token expiration and revoking are two different things.
- Expiration only happens for web apps, not for native mobile apps, because native apps never expire.
- Revoking only happens when (1) uses click the logout button on the website or native Apps;(2) users reset their passwords; (3) users revoke their tokens explicitly in the administration panel.
A JWT token that never expires is dangerous if the token is stolen then someone can always access the user's data.
Quoted from JWT RFC:
using System; | |
using System.Collections.Concurrent; | |
using System.Collections.Generic; | |
using System.ComponentModel; | |
using System.Timers; | |
namespace DebounceUtils | |
{ | |
/// <summary> | |
/// Event debouncer helps to prevent calling the same event handler too often (like mark Dirty or Invalidate) |
Picking the right architecture = Picking the right battles + Managing trade-offs
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
namespace BloomFilter | |
{ | |
using System; | |
using System.Collections; | |
/// <summary> | |
/// Bloom filter. | |
/// </summary> | |
/// <typeparam name="T">Item type </typeparam> | |
public class Filter<T> |
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t