Shulou(Shulou.com)06/03 Report--

cloning

Typically, a scalable web service on a public server is hidden behind a Load Balancer. This Load Balancer distributes the load (requests from users) evenly across a group of servers or server clusters. What does that mean? For example, if a user accesses your service, his first request may be served by a second server, his second request by a ninth server, and his third request by a second server.

For this user, the result he gets should be the same every time, regardless of which server the service is provided by. This is the first golden rule of scalability: each server contains exactly the same code base and does not store any user-related data, such as sessions or user information, on local disk or memory. Sessions need to be stored centrally so that every server can access them. It can be an external database or an external persistent cache, such as Redis. Storing sessions in a persistent cache will have better performance than an external database. The reference to "external" here means that the data store is not located on these application servers, but in a data center close to your application server.

But how do we deploy this? How do you make sure that when the application code changes, it will be sent to all servers and none of them will still use the previous code? Fortunately, this thorny problem has been solved by a wonderful tool called capistrano, which you need to learn a little bit about.

After solving the session and synchronizing new versions on multiple servers, all you need to do is clone your machine and mirror it and deploy your latest code. You can refer to AMI service provided by Amazon (Amazon Machine Image).

Your server can now scale horizontally and handle thousands of concurrent requests.

database

But you find that the app becomes more and more to eventually crash. The reason for the problem: MySql, isn't it?

Now, instead of adding more machines, you have two options:

1, stick with MySql and let it work well. Do master-slave replication (slave reads, master writes) and upgrade master to keep adding more memory. As you continue to optimize, you will use the usual methods of database fragmentation, de-scaling, SQL tuning, etc. At this point, the cost of any single operation on the database becomes quite expensive.

Switching to a more scalable NoSQL database, such as MongoDB or CouchDB, join queries now need to be done at the application code level.

Now that you have a scalable solution for your database, you no longer have to worry about storing terabytes of data, and the world looks so good.

cache

When a large number of data requests are sent to the database and you find it slow again, the solution is to increase the cache.

Cache refers to memory cache, such as common memory database Memcached or Redis, do not use file cache, it will make your server cloning and automatic scaling very painful.

But back to memory cache, cache is a simple key-value store and should be somewhere between application and data store. Any time your application needs to read data, it should first try to get data from the cache, and only try to read data from the database if it cannot read data from the cache. Why would you do that? Because caching is lightning fast, it holds data sets in memory and can be processed quickly. For example, Redis can handle thousands of reads every second.

Visit flow: green for the first visit, blue for the second and after:

There are two modes of caching data, one old and one new:

1, cache database query, this is still the most common cache way, when you do a query, the data set cache, through the hash query string as a key. The next time you query, check if there are results in the cache. There are some problems with this approach, the main one being expiration. When a chunk of data in a table changes, you need to delete all caches of query strings that contain that chunk.

2. Cache objects, which I highly recommend, and which I use often.

Some objects suitable for caching:

User Session (never stored in database)

Fully presented blog post

activity stream

user friends and stuff.

asynchronous

Imagine that you want to buy bread at your favorite bakery, so you walk into the bakery and ask a clerk to buy bread, but the bread is sold out. You're told your bread will be ready in two hours, which is annoying, isn't it?

To avoid this "wait a minute" scenario, you need to be asynchronous. For example, when bread is available, the clerk will deliver it to your home. In general, there are two asynchronous paradigms:

1. Let's go back to the ordinary bread buying scenario. The first asynchronous processing flow is: "Cook the bread in the evening and sell it the next morning." This does not require waiting for the customer. For a web application, this means doing time-consuming work ahead of time so that it can be done in a short time. Often this pattern is used to convert dynamic content into static content. For example, some web pages in CMS are rendered in advance, and these HTML files are stored locally. Use timed tasks, possibly through scripts called hourly schedules. This pre-computation of common data can greatly improve the scalability and performance of websites and web apps. These pre-rendered HTML pages can be scripted to the CDN. Your website will be super responsive and able to handle thousands of visitors per hour!

2, back to the bakery, sometimes customers may have some special needs, otherwise add "Happy Birthday" and other decorations on the bread. Bakeries don't know in advance what this type of customer wants, so when the customer arrives, they must immediately start a task and tell him: "Come back tomorrow! "For the web, this means asynchronous tasks. Here's a typical workflow: A user comes to your site and starts a computationally intensive task that takes a few minutes to complete, so the front end of the site sends a task to the task queue and tells the user that your task is already in progress and you can continue browsing. A task queue is constantly checked for processing by workers who are processing the task. If there is a new task, work will process it and send a completed message after a few minutes. The frontend constantly checks (e.g. polls) whether the task has been processed and notifies the user once it has been processed. If you want to learn more, I recommend you to check out Rabbit MQ, an excellent middleware that implements asynchronous message queues. You can also use ActiveMQ or a simple Redis list. Asynchronous message queues may seem complicated, but it's worth the time to learn and implement.

If you're doing something time-consuming, try asynchronous.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.