In addition to the server architecture supporting high concurrency, high concurrency business also needs to design a reasonable development plan according to the business requirements and architecture system. Here, based on a practical business scenario analysis and development ideas, listed the points that need to pay attention to high concurrency interface, as well as the clever thinking on the design, encourage each other, hope to echo

The business scenario

  • Business:
    • Today good
  • Interactive end:
    • IOS/Andorid
  • Requirement points :(the actual business will be more complex, so requirement points are simplified for easy understanding)
    • Provide the latest good goods information list, support pagination
    • You need to obtain the latest list of commodity data at all times, and the commodity information will change in the following cases
      • Commodity data field updates (artificial editing, heat field updates, etc.)
      • Goods are updated irregularly, and a large number of goods will be updated in a fixed period of time (at present, the new volume is large at 10:00 /20).
      • – Items will be reordered at regular intervals (based on sales, exposure, clicks, etc.)
    • Duplicate goods cannot appear during the loading process
    • Clients and servers need to consider the interactive experience of loading goods
  • Ultimate goal:
    • Supports service stability under high concurrency

Design ideas

Premise:

  • [Commodity service API]: Obtain commodity data through the API provided by the commodity service. When the commodity is updated, the field is updated and the sorting is updated, the latest data can be obtained through the API (DB query, supporting the acquisition of commodity data in the future).
  • The cache usingRedis

Cache update analysis:

  • Caching of commodity data to Redis: To support high-concurrency query services, data needs to be cached
  • Provide the commodity cache refresh interface: the commodity display needs to be real-time, and the latest data needs to be displayed all the time. When the commodity changes, we need to refresh the commodity cache data
  • Support future time cache update in advance: In order to better support immediacy, especially in a fixed period of time when a large number of new items, cache update will be slow, so we need to prepare the future time cache data in advance
  • Note the following when refreshing the cache: Do not display no data in the foreground during the cache update
  • Item cache supports version number differentiation: Each cache update generates a new cache Key with a data version number, and data is stored in the corresponding cache version Key
  • The cache version Key is stored in the list: The list can be used to filter out the latest version number available at the current time

Item cache update design:

  • Interface parameter: updateTime[Update at](null), the default is equal to the current time, can be transmitted to the future time
  • Each time the cache is refreshed a new data version number is generated as[Item cache Key name], store the data in the cache Key corresponding to the version number, so need to generate a unique string, here we put[Update at]Is used as the Key name of the cache, as explained later
  • The first request[Commodity service API]To obtain[Update at]The corresponding commodity data, then the data field processing, sorting, and finally the final commodity data update to[Item cache Key name]The Redis SortedSet
  • After the item is cached successfully, the[Item cache Key name]endures[Version Number Collection]Redis SortedSet, at the same time[Update at]As the sorting value
  • [Item cache Key name]=[Update at]The purpose of this design is to support the advance update of future time version data, and can be sorted by SortedSet, filter out the latest version number of the current time

Cache structure diagram

Today’s good goods API design:

  • Interface parameters: version: indicates the data version number (which can be empty), and pageIndex: indicates the page number
  • Response JSON data: Datas: set of commodity data, CurrentVersion: current data version
  • [Current latest version number]:[Version Number Collection]SortedSet mechanism is used to obtain the data version number that can be used at the current time, for example: [current timestamp]-[(current timestamp -1h) timestamp], sort, get the latest version number as the latest version number.
  • Client requests when the user browses an item【 Today's good goods API】You need to upload the version number and page number, if it is the first time (pageIndex =1, the home page), will get[Current latest version number]And returns the latest product data
  • Client local cache data back home page version number, the subsequent pages need to report the client cache version number, the API returns the version number corresponding goods paging data, the purpose of this design is when users continue to load pages behind the data will not be repeated data (data will not be updated regularly, avoid the user load to duplicate data, such as: Commodity A was originally the data on page 1, but the data is updated to page 2.)
  • When requesting home page data, the version number reported by the client =[Current latest version number], does not carry on the data cache query, directly returns the empty data (data unchanged), the customer service side does not need to re-render the commodity list, and can avoid the infinite drop-down refresh of the server pressure
  • If the version parameter is not uploaded, obtain it[Current latest version number]And the latest data is returned. If the data version number parameter is uploaded, the paging data corresponding to the version number is obtained

Other points to note:

  • The version number accumulates indefinitely
    • [Version Number Collection]As time goes by, version data accumulates. You need to delete the latest version at each update, and run SortedSet to filter out version numbers that are smaller than the timestamp (current time -1 day)
  • Fault-tolerant processing
    • To obtain[Current latest version number]When operating[Version Number Collection]Collection, obtain an hour recently, namely operating SortedSet [the current timestamp] to [timestamp] (the current time – 1 h) within the scope of the version number, and then from big to small order version number, filter press this number, the goods and have the version number relative to the data, if there is no goods data, traverse down, until a version number to return to conform to the rules

Double eleven mode:

  • Level 1 cache
    • Item data is briefly cached in the site service area Cache

Downgrade plan:

  • Resource monitoring, automatic degradation
  • After starting the downgrade scheme, the customer service will pull the commodity data from the CDN
  • Commodity paging data generates JSON data files stored in the CDN

Architecture diagram

conclusion

  • Some of the practical schemes of high-concurrency interface design mentioned above may be more specific to this business scenario, but the ideas are common. The key point is to understand the design ideas
  • Factors to consider when developing a high concurrency interface:
    • The interface properties
    • Interface stability
    • Fault-tolerant mechanism
    • Server side stress: it is possible to reduce server side stress and interact with clients
    • Service degradation: Degraded when resources are under high pressure

Welcome to pay attention to my Github, wechat public number “big talk WEB development”, public number search :(sflyq_) if there is any want to say, please leave a message oh, I will modify the content of doubt according to your suggestions, please state the original address, thank you for your cooperation