Hướng dẫn mua cho Enterprise Caching, một e-book đi kèm với giải pháp enterprise caching để cung cấp hiệu suất cao nhất quán tính trong khi mở rộng quy mô, hiện có sẵn. Tải miễn phí bên dưới.
Trong nhiều thập kỷ, cơ sở dữ liệu đã làm việc thầm lặng phía sau điều khiển ứng dụng và trang web làm cho trải nghiệm số động và thích ứng hơn. Nhưng đã có một vấn đề cơ bản với mô hình này. Những cùng cơ sở dữ liệu đó cũng đã làm cho ứng dụng chậm hơn.
Đó là nơi caching xuất hiện. Nó lấy dữ liệu được lưu trong cơ sở dữ liệu trên ổ cứng server và di chuyển nó đến một nơi tạm thời nơi nó có thể được truy cập nhanh hơn và hiệu quả hơn nhiều. Kết quả là, hoạt động phức tạp, tốn năng lượng, và tốn thời gian để lấy dữ liệu chỉ cần được thực hiện một lần. Từ thời điểm đó, dữ liệu có thể được truy xuất nhanh chóng và hiệu quả từ cache.
Tất nhiên, khi công ty của bạn lớn hơn và phạm vi ảnh hưởng tăng, cược cược cao hơn và biên độ lỗi trở nên mỏng như lưỡi dao. Đột nhiên, caching không còn là nice-to-have (có thì tốt) – nó là must-have (bắt buộc). Điều thuận tiện cho công ty quy mô nhỏ trở thành thiết yếu cho doanh nghiệp quy mô lớn cạnh tranh. Và thất bại không phải là một lựa chọn.
Xuất hiện enterprise cache. Được xây dựng trên nền tảng vững chắc của cache cơ bản, nó cung cấp một bộ tính năng mà doanh nghiệp yêu cầu để theo kịp nhu cầu ngày càng tăng, bao gồm high availability (tính sẵn sàng cao), hỗ trợ sản phẩm chính hãng, hiệu suất sub-millisecond (dưới mili-giây), replication phân tán hoàn chỉnh (fully distributed replication), và một cách tiết kiệm chi phí để quản lý tập dữ liệu phức tạp của bạn. Nó có khả năng mở rộng hơn, chịu lỗi hơn, và có, giá cả phải chăng hơn.
Đã đến lúc chuyển sang enterprise caching?
Lý do cho việc áp dụng giải pháp enterprise caching là đơn giản: Khi bạn cần mở rộng quy mô và không thể chịu đựng thất bại. Làm thế nào để biết khi nào đã đến lúc áp dụng giải pháp enterprise caching? Có một số yếu tố cần xem xét:
1. Cơ sở dữ liệu gốc của bạn không mở rộng quy mô hiệu quả
Con kiến nhỏ bé là một trong những sinh vật tuyệt vời nhất trên hành tinh. Nó có khả năng nâng gần 5.000 lần trọng lượng cơ thể của nó. Qua nhiều thế kỷ, nhiều nhà khoa học (và người làm phim khoa học viễn tưởng) đã thắc mắc điều gì sẽ xảy ra nếu chúng ta lấy sức mạnh khổng lồ của con kiến nhỏ và mở rộng nó đến kích thước con người. Đáng tiếc, con kiến không scale (mở rộng). Nếu chúng ta tạo ra một con kiến cỡ người đồng nghiệp, chân nó sẽ sụp đổ dưới trọng lượng cơ thể của chính nó.
Mặc dù nguy hiểm của việc mở rộng cache không đẹp mắt như vậy, chúng chia sẻ một số tương đồng. Khi chúng mở rộng, cache tiêu chuẩn thường gặp hai loại rào cản: giới hạn lưu trữ (storage) và giới hạn tài nguyên (resource limits). Cái trước mô tả lượng không gian có sẵn để cache dữ liệu. Cái sau đề cập đến khả năng thực hiện các chức năng cần thiết, bao gồm lưu trữ và truy xuất dữ liệu đã cache.
Giải pháp có thể đơn giản, nhưng có thể không bao giờ kết thúc. Khi bạn chạm đến giới hạn lưu trữ, giải pháp tiêu chuẩn rõ ràng: Tăng lưu trữ. Nếu bạn không đủ sức để xử lý tất cả tài nguyên, tăng băng thông và sức mạnh xử lý. Với vertical scaling (mở rộng dọc), bạn tăng tài nguyên được cấp cho cache để vận hành.
On-prem, điều này thường có nghĩa là thay thế server hiện tại bằng một server mạnh hơn có nhiều RAM, sức mạnh xử lý, băng thông mạng, hoặc cả ba. Nếu cache của bạn trên đám mây, nó có thể nghĩa là chuyển sang instance lớn hơn. Một phương án khác, horizontal scaling (mở rộng ngang), liên quan đến thêm nhiều node vào cụm instance đang xử lý cache của bạn mà không thay đổi kích thước instance cache riêng lẻ. Tóm lại, vertical scaling nghĩa là tăng theo kích thước, trong khi horizontal scaling liên quan đến tăng theo số lượng.
2. Chi phí caching đang trở nên cấm đoán
Mở rộng liên tục kích thước cache để đáp ứng nhu cầu tăng có thể tạm thời giải quyết vấn đề, nhưng với giá bao nhiêu? Nếu bạn giống nhiều người, đồ đạc của bạn đã vượt quá nhà hoặc căn hộ và bạn có thể phải thuê một hoặc nhiều kho chứa. Nếu vậy, bạn nhận ra rằng trong hầu hết trường hợp, chi phí nhồi nhét đồ đạc vô giá trị vào kho chứa giống hệt chi phí lấp đầy nó bằng đồ cổ quý giá.
Caching cơ bản hoạt động theo cách tương tự. Dữ liệu thường dùng hoặc giá trị cao được xử lý y hệt dữ liệu ít phổ biến hoặc ít quan trọng hơn. Không chỉ vậy, khi bạn hết không gian cache, bản chất của dữ liệu đó là không liên quan. Bạn hết chỗ. Đáng tiếc, thêm không gian cache có thể đắt đỏ. Redis on Flash (một thành phần của Redis Enterprise) giúp giữ chi phí cache của bạn trong kiểm soát bằng cách thiết lập một hierarchy caching (hệ thống phân cấp cache). Giá trị cache được dùng chủ động hơn được lưu trong RAM, trong khi những cái ít dùng hơn có thể được duy trì trong flash memory lớn hơn và rẻ hơn nhiều.
3. Bạn không thể còn phụ thuộc vào một master đơn lẻ
Thêm node vào cache có thể đáp ứng nhu cầu traffic tăng, nhưng nó chỉ giải quyết một phần vấn đề. Caching cơ bản cho phép read replicas bổ sung, một phương pháp horizontal scaling cải thiện hiệu suất đọc bằng cách phân phối tải đọc trên nhiều server. Đáng tiếc, bạn vẫn bị giới hạn ở một master duy nhất để xử lý tất cả writes (ghi).
Bị giới hạn ở một master đơn lẻ có thể tạo ra vấn đề nếu triển khai của bạn trải nhiều region hoặc dùng nhiều provider hoặc nhiều cloud. Nếu ứng dụng của bạn có cơ sở khách hàng xa xôi, phụ thuộc vào một master đơn lẽ có thể tạo ra một bottleneck (nút thắt) làm tê liệt. Đó là vì tất cả request write của bạn, bất kể nguồn gốc, phải được dẫn đến một vị trí giới hạn.
Điều đó hơi giống như đi vào một nhà hàng mang đi nơi bạn có thể lấy đơn hàng từ nhiều cửa sổ, nhưng chỉ có một quầy thu ngân mở nơi bạn được trả tiền. Với Active-Active Geo-Deployment từ Redis Enterprise, bất kỳ instance master nào, bất kể region hoặc provider của nó, có thể xử lý cả request read và write.
4. High availability đã từ xa xỉ trở thành thiết yếu
Với ứng dụng quy mô nhỏ, những lúc ứng dụng bị down thỉnh thoảng có thể là sự khó chịu và xấu hổ. Một outage (gián đoạn) cấp doanh nghiệp là một game changer (thay đổi cuộc chơi). Một lỗi xử lý bóng trong trận baseball little league là đáng tiếc. Một lỗi tương tự trong World Series có thể tốn hàng triệu đô la.
Tương tự, một thất bại về tính sẵn sàng không còn chỉ là sự phiền toái. Nó là một trách nhiệm thực sự. Thực tế, tùy vào SLA bạn có với khách hàng, nó có thể đặt bạn vào nguy cơ pháp lý. Đáng tiếc, caching cơ bản không cung cấp bảo đảm固有 về scaling, security, hay high availability. Mặc dù về mặt lý thuyết có thể xây dựng nhiều bảo vệ đó trên cache open-source của bạn, những giải pháp tự làm này thường đi kèm với đau đầu đặc biệt và chi phí ẩn.
Tất nhiên, một số cache Redis bên thứ ba cung cấp 3-9s availability, nhưng chỉ trên một region đơn lẻ và không có data persistence, chỉ có snapshot. Nếu ứng dụng của bạn bị giới hạn, đó là một giải pháp bị giới hạn. Nhưng nếu công ty và/hoặc cơ sở khách hàng của bạn quốc tế, đó là không đủ. Redis Enterprise Cloud cung cấp 5-9s SLA trên một hoặc nhiều region. Nó hỗ trợ data persistence và backup mà không ảnh hưởng hiệu suất. Ngoài ra, nó cung cấp automatic cluster recovery (tự động phục hồi cụm) và pure in-memory replication (sao chép in-memory thuần túy).
Bắt đầu thu hút khách hàng với enterprise caching
Tất cả những nhu cầu tăng này khi công ty mở rộng có thể dẫn đến load time chậm hơn, có thể làm khách hàng lâu năm chán nản và dẫn đến từ chối rộng rãi bởi khách hàng tiềm năng mới. Thích hay không, response time là một thành phần quan trọng của trải nghiệm trực tuyến.
Theo Unbounce, 70% user nói rằng load time ảnh hưởng đến ý nguyện mua từ nhà bán lẻ trực tuyến. Nghiên cứu cho thấy ứng dụng có khoảng 100 ms trước khi user cảm thấy họ đang chờ. Đó là một phần ba thời gian nháy mắt. Nếu khách hàng của bạn có thể nháy mắt trong khi ứng dụng của bạn đang load, có khả năng cao bạn đã mất họ.
Và đó không chỉ là vấn đề quyết định mua hàng. Một nghiên cứu của Salesforce thấy 83% khách hàng coi trải nghiệm quan trọng ngang ngang sản phẩm và dịch vụ của công ty.
Cuối cùng, trong thời đại media viral, một trải nghiệm xấu riêng lẻ của khách hàng khó lòng bị cô lập lâu. Khi mọi người có trải nghiệm không hài lòng trên trang web, họ thường không giữ nó cho mình. Ngược lại, theo Salesforce, 61% khách hàng chia sẻ trải nghiệm xấu đó với người khác. Kết quả, khuyết điểm ứng dụng của bạn có thể kích hoạt phản ứng dây chuyền của sự ác cảm khi tin lan truyền nhanh khắp cơ sở khách hàng tiềm năng.
May mắn thay, có một đường ray bạc cho bộ thống kê令人清醒 này. Cùng nghiên cứu Salesforce thấy 70% khách hàng có xu hướng chia sẻ trải nghiệm tốt của họ với người khác. Nếu công ty của bạn đang lớn và bạn muốn xây dựng một nền tảng khách hàng vui vẻ mới thay vì mất khách cũ, enterprise caching có thể chứng minh là chính thứ bạn cần để đặt nền tảng cho sự mở rộng tiềm năng không giới hạn của trải nghiệm số của họ.
Sẵn sàng đưa database caching của bạn lên cấp doanh nghiệp?
Để biết thêm thông tin, hãy xem Hướng dẫn mua cho Enterprise Caching miễn phí của chúng tôi.