web service • Large web service handles too many requests • Large web service has too many items • In general, page view of item overrepresents in all requests • Usually, page view is only read-only processing except logging • If it changes to write processing? • Write's scaling is more difficult than read's • Asynchronous processing is essential
by Go (net/http) • MySQL pvpoold pvpoold nginx MySQL pvpool.local by consul DNS : HTTP protocol : MySQL protocol The gopher was designed by Renée French
latest page view as real-time as possible (e.g. within a few seconds) • Respond as low latency as possible (e.g. within a few milli-seconds) • Load Characteristics • High throughput (Equal to page view of all items plus alpha) • Write-heavy
types.ItemID • PVMap -> map[types.ItemID]int • Storer -> Fetch page view of item in Slot and store to PVMap • Flusher -> Fetch page view of item in PVMap and Issue SQL to MySQL periodically • Storer & Flusher are also represented by goroutine
SQLs to MySQL by aggregating page view per item • eg. UPDATE pv = pv + 5 instead of five of UPDATE pv = pv +1 • Flusher • Issue SQLs to MySQL periodically • Mitigate load of MySQL by timer control
some item ID to multiple Slots • Slot in which some item ID is stored is uniquely identified by its value • Because Go's map iteration order is random • So flushed item ID order in each Slot is not fixed