Nói tới nền tảng Artificial Intelligence, sẽ thật thiếu sót khi không nhắc tới FPT.AI. Nền tảng FPT.AI là sản phẩm mới ra đời, áp dụng các kỹ thuật học máy tiên tiến về xử lý ngôn ngữ tự nhiên. Sản phẩm hỗ trợ xây dựng hệ thống giao tiếp tự động để tích hợp vào các nền tảng hội thoại (Facebook Messenger,…), các ứng dụng hội thoại do doanh nghiệp tự phát triển và các thiết bị thông minh như robot, điện thoại di động, thiết bị điều khiển… FPT.AI hỗ trợ các ứng dụng sử dụng giao diện tương tác với người dùng bằng giọng nói hoặc văn bản.
Video này sẽ cho bạn thấy hướng đi mà FPT.AI đã chọn khi ứng dụng AI trong việc “Mô phỏng bộ não con người” do chính chuyên gia Nguyễn Thượng Tường Minh – Product Manager của FPT.AI Platform chia sẻ!
Hẳn là một “thu hoạch” thú vị phải không nào! Hơn thế nữa, bạn sẽ còn tìm thấy nhiều topics “hợp gu” của mình hơn tại Vietnam Mobile Day 2019 cùng với các chuyên gia “SIÊU CHẤT”!! Đừng bỏ lỡ session nào bạn nhé, theo dõi fanpage để update nào!
HÉ LỘ MỘT SỐ TOPICS HOT NĂM NAY:
▶️ “Khởi nghiệp game: Làm sao để sống sót và kinh nghiệm khởi nghiệp game studio” | Nguyễn Đình Khánh – CEO/Founder at ▶️ “Building a server-less DApp on Mobile using Blockchain” | Lê Yên Thanh – CTO, CoFounder at ▶️ “Unity và những lời khuyên tốt nhất cho Indie và small studio” | Lê Huy Hoàng at Field Engineer at ▶️ “How small mobile applications with the use of AI / Data projects can help big problems. A Vietnam Case Study” | Vương Hoàng Kim – Head of Products at . ▶️ “WhatsApp-clone Real-Time & Offline Serverless Messaging Mobile/Web App using AWS Amplify & AppSync” | Nguyễn Nhất Thanh – Director of Technology & Agile Digital Transformation at . ▶️ “The State of Mobile in Vietnam: 2019 Insights and Benchmarks” | Nana Phan – SEA Sales Manager at ▶️ “High-performance image recognition application with 50 millions records in real-time” | Hoàng Tùng – CEO at ▶️ “Doing online experiments the proper way: true effect or due to chance?” | Uyên Nguyễn – Data Scientist at ▶️ “X3 tốc độ phát triển dự án game với Scrumban” | Lê Giang Anh – Head of Product at ▶️ “Cross Platform Development: Flutter vs React Native” | Đặng Ngọc Đức – Mobile Developer at
============================
THÔNG TIN CHI TIẾT VÀ ĐĂNG KÝ:
Book now: http://topdev.vn/s/X5D57UHI
Website: https://mobileday.vn/
Time: Hồ Chí Minh – 06/06/2019 | Hà Nội – 14/06/2019
Event team: event@applancer.net | 028 6681 3236 hoặc Ms. Thoa | thoa.nguyen@applancer.net | 038 5098 969
CODE giảm 30% vé tham dự cho độc giả: TOPDEVBLOG@VMD19
Hệ thống của các bạn bình thường xử lý được 10 request/s. Nếu bây giờ số lượng request đó tăng lên thành 100, 1000 request/s thì bạn có dám khẳng định hệ thống của bạn sẽ chạy ngon không?
Để có thể phán đoán được nó chạy ngon hay không thì việc test tải hệ thống trở nên vô cùng quan trọng.
Nói là test tải hệ thống, nhưng nếu mà yêu cầu bạn lên plan để test chắc hẳn các bạn cũng chẳng biết nên bắt đầu từ đâu, làm thế nào để đánh giá quá trình test của mình là thành công. Hay đơn giản chỉ cần chạy mấy tool benchmark là xong?
Vậy hãy cùng đọc bài này để giải đáp được thắc mắc đó nhé.
Mục tiêu bài viết:
Hiểu được việc test tải hệ thống là làm những gì.
Biết cách làm thế nào để cải thiện hệ thống.
Bài này hơi dài 1 tí, các bạn cố gắng đọc hết nhé. Sau khi đọc xong sẽ hoàn toàn tự tin để có thể lên được plan test tải hệ thống.
Mục đích của việc test tải hệ thống
Dưới đây là 3 mục đích chính của việc test tải hệ thống:
**Tìm điểm bottleneck (nút cổ chai): **Đưa ra 1 số Use Case có thể xảy ra trong tương lai (ví dụ như sắp tới đưa ra campaign hot, số lượng người đăng kí lúc đó sẽ tăng đột biến …). Sau đó ứng với mỗi Use Case sẽ đo xem thời gian response của hệ thống là bao nhiêu. Tìm điểm bottleneck (nút cổ chai).
**Cải thiện hệ thống: **Sau khi biết được điểm bottleneck sẽ tiến hành đi cải thiện hệ thống.
Xác nhận tính scale của hệ thống.
Cụ thể cùng đi xem những Use Case nào hay gặp trong thực tế nhé.
Đưa ra Use Case và đo response của hệ thống
Dưới đây là 1 vài Use Case mình thấy hay gặp nhất trong quá trình vận hành hệ thống.
Đối với mỗi Use Case, chúng ta sẽ đi đo đạc xem thời gian response của hệ thống là bao nhiêu và tiến hành cải thiện hệ thống nếu có.
Use Case 1: Sau khi hệ thống được đưa ra, số lượng người dùng đăng kí vào hệ thống tăng đột biến.
Với những hệ thống mà nhiều người quan tâm thì khi release sẽ có rất nhiều người vào đăng kí hệ thống.
Ví dụ như tuần sau sẽ release hệ thống ”dự đoángiá đề chuẩn 80%” chẳng hạn. Nếu có hệ thống đó ra đời, mình khẳng định sẽ có rất nhiều người vào đăng kí vào thời điểm đó.
Vậy để đảm bảo hệ thống của bạn chạy không vấn đề gì với số lượng lớn người đăng kí vào thời điểm đó thì việc test tải hệ thống trước khi release là điều vô cùng quan trọng.
Use Case 2: Sau khi hệ thống chạy được 1 thời gian thì dữ liệu càng ngày càng nhiều.
Khác với Use Case 1 thì Use Case này chủ yếu tập trung vào vấn đề dữ liệu trong DB càng ngày càng to ra, dẫn đến tốc độ query trong DB cũng càng ngày càng chậm xuống. Kể cả có đánh index chuẩn đi chăng nữa, nhưng nếu dữ liệu trong DB mà tăng lên thì dẫn đến việc index không thể lưu hết trên Memory được. Kết quả hiệu năng của câu query sẽ giảm xuống.
Với Use Case này thì việc test tải hệ thống cũng khá quan trọng để đảm bảo thời gian response hệ thống là nhanh nhất có thể.
**Use Case 3: **Nhờ vào việc đưa ra campaign mà số lượng người dùng access vào hệ thống tăng đột biến.
Với Use Case này mình thấy hay gặp nhất và việc đưa ra plan để test tải trước khi release là điều không thể thiếu.
Ví dụ như nhà mạng Viettel chuẩn bị có đợt khuyến mãi nạp thẻ 100k sẽ được tặng 500k. Các bạn nghĩ sao về campaign này. Chắc hẳn số lượng người nạp thẻ lúc đó phải kinh khủng lắm.
Cải thiện hệ thống
Bình thường chúng ta hay làm việc với dữ liệu nhỏ thì mình khẳng định ít ai để ý đến vấn đề hiệu năng hay 1 số lỗi xảy ra như out of memory … Nhưng 1 khi chạy hệ thống đó với dữ liệu lớn thì chắc chắn sẽ ra nhiều vấn đề.
Như ngày trước mình có làm 1 chức năng upload file csv về thông tin người dùng và gửi tin nhắn đến tất cả người đó. Bình thường mình chỉ test file csv tầm 100 record, cùng lắm 1000 record thấy chạy khá ok.
Nhưng khi đưa cho khách hàng dùng, bên họ upload file csv toàn tầm 1 triệu, 10 triêu record. Lúc đó hệ thống lăn quay ra chết. Vì mình toàn load tất cả dữ liệu trong file csv vào 1 biến duy nhất. Kết quả tràn bộ nhớ.
Do đó ở đây mình muốn nói rằng để đảm bảo hệ thống chạy có ngon hay không, có đáp ứng được dữ liệu lớn hay không thì việc test hệ thống với dữ liệu lớn là điều cực kì quan trọng.
Vừa test vừa đi cải thiện hệ thống là 1 trong những mục đích quan trọng nhất.
Xác nhận tính scale của hệ thống
Đặc thù của những hệ thống đang được xây dựng trên môi trường Cloud như AWS, GCP, Azure đó là nếu số lượng request tăng lên thì sẽ tăng thêm server, nếu số lượng request giảm xuống thì sẽ giảm server.
Để đáp ứng được nhu cầu này thì cần phải nắm rõ tính scale của hệ thống. Cụ thể phải nắm bắt được những điểm sau:
Cấu trúc hệ thống có thể xử lý được 1 số lượng throughput nào đó (ví dụ như 100 request/s, 1000request/s, 2000 request/s, 5000 request/s)
Hệ thống xử lý tối đa throughput là bao nhiêu?
Cái ý thứ nhất là điểm quan trọng nhất cần phải nắm bắt được.
Ví dụ như throughput tăng lên 2 lần thì chỉ cần tăng số lượng web server lên 2 lần là được ak? Hay phải tăng số lượng DB lên 2 lần? Ngược lại khi số lượng request giảm đi 2 lần thì cần giảm cái nào đi thì được? Những điểm như này cần phải nắm bắt.
Cái ý thứ 2 thì không cần phải nắm bắt cũng được. Nhưng nếu tương lai muốn cung cấp hệ thống xử lý nhiều request hơn nữa thì việc phán đoán xem với cấu trúc hiện tại thì có scale được hay không? cần phải thiết kế lại hệ thống không? là điều không thể thiếu.
2 chỉ báo quan trọng khi đo hiệu năng
Mình chắc hẳn khi tối ưu hệ thống, ai cũng gặp những case kiểu như: ví dụ như nếu đưa cái plugin này vào thì wordpress sẽ chạy nhanh gấp 10 lần …
Tuy nhiên, cái việc “nhanh gấp 10 lần” ở đây tức là đang nói đến vấn đề gì? thì chúng ta cần nên để ý tới.
Có thể đang nói về tốc độ của hệ thống?
Thế nhưng để đánh giá về tốc độ thì hiện nay có 2 chỉ bảo chắc hẳn mọi người cũng thường hay nghe thấy đó là throughput (lưu lượng) và latency (thời gian trễ).
Cùng nhau tìm hiểu xem 2 chỉ báo này khác nhau thế nào nhé.
Throughput
Chỉ báo Throughput muốn nói đến lượng công việc xử lý trong 1 đơn vị thời gian. Về Website thì muốn nói đến số lượng request xử lý trong 1 giây. Nó còn được gọi là rps (Request per second).
Quay lại ví dụ trên, 「sau khi đưa plugin này vào hệ thống thì tốc độ wordpress sẽ tăng lên gấp 10 lần」nếu đang nói về throughput thì tức là số lượng page hiển thị trong 1 giây tăng lên 10 lần.
Latency
Chỉ báo Latency là tổng thời gian xử lý của 1 việc nào đó.
Quay lại ví dụ trên, 「sau khi đưa plugin này vào hệ thống thì tốc độ wordpress sẽ tăng lên gấp 10 lần」nếu đang nói về latency thì tức là thời gian response của hệ thống đang từ 1s bây giờ giảm xuống còn 0.1 giây.
Throughput và Latency trong hệ thống
Đa số các hệ thống ngày nay sẽ không chỉ gồm 1 web server mà còn bao gồm rất nhiều thành phần khác nữa như database server, cache server …
Hiệu năng của từng con server đó cũng có thể gây ảnh hưởng đến hiệu năng của toàn bộ hệ thống. Ví dụ như tốc độ query của DB chậm thì cho dù con web có xử lý nhanh đi chăng nữa thì thời gian xử lý của toàn bộ hệ thống vẫn chậm. Vì con DB nó gây ảnh hưởng đến con Web.
Throughput của toàn bộ hệ thống là giá trị throughput nhỏ nhất của từng hệ thống con.
Latency của toàn bộ hệ thống là giá trị tổng cộng của lantecy của từng hệ thống con.
Đến đây có vẻ hơi trừu tượng đúng không. Vậy mình lấy 1 ví dụ để các bạn dễ hình dung nhé.
Thay vì lấy ví dụ hệ thống gồm web server, database server … thì mình lấy ví dụ về đường cao tốc.
Mình thấy khá dễ hiểu khi áp dụng vào throughput và latency.
Nhìn vào hình ảnh bên trên ta có thể thấy được:
throughput của đoạn đường trên là 500 xe / 1 tiếng
latency của đoạn đường trên là 15 tiếng (15 = 3 + 4 + 8)
Cải thiện hệ thống
Để cải thiện hệ thống thì chúng ta cần phải tăng số lượng throughput và giảm latency.
Cùng đọc phần tiếp theo để hiểu xem cụ thể là làm thế nào nhé.
Cải thiện throughput
Vậy làm thế nào có thể cải thiện được throughput của hệ thống.
Như ví dụ về đoạn đường ở bên trên ta thấy, nếu ta cải thiện sai chỗ thì hiệu năng của hệ thống cũng không thể tăng được.
Ví dụ như trong đoạn đường từ Hà Nội đến Thanh Hoá, cho dù có thêm mấy làn đường để tăng số lưu lượng xe từ 1000 đến 5000 xe đi chăng nữa thì tổng throughput của hệ thống cũng không thể tăng được, vẫn chỉ là 500 xe thôi. Lí do tại sao?
Bởi vì throughput của đoạn từ Vinh đến Đà Nẵng đang gây cản trở đến toàn bộ hệ thống, bởi vì 5000 xe mà đi vào đoạn đường chỉ max 500 xe thì đương nhiên vẫn bị tắc rồi. Có cố cũng không thể đi được.
Nên nếu cải thiện thì nên cải thiện đoạn đường này là tốt nhất.
Và cái đoạn từ Vinh đến Đà Nẵng này người ta gọi là bottleneck (nút cổ chai).
Nhờ vào việc xác định được bottleneck mà có thể khiến ta dễ dàng cải thiện throughout của toàn bộ hệ thống.
Ví dụ về cải thiện throughput
Quay lại ví dụ về đoạn đường ở bên trên. Giả sử như đoạn đường từ Vinh đến Đà Nẵng đang thi công và xảy ra tắc đường. Hiện tại số lượng xe lưu thông trên 1 giờ chỉ còn có 100 xe.
Khi này throughput của toàn bộ hệ thống giảm xuống còn 100 xe / 1 giờ.
Nếu như chúng ta giải quyết được vấn đề tắc đường này thì chắc chắn throughput của hệ thống sẽ tăng lên. Giả sử như sau khi giải quyết xong tắc đường đoạn từ Vinh đến Đà Nẵng thì bây giờ lưu lượng xe đã tăng lên thành 2000 xe / 1 giờ.
Lúc này throughput của hệ thống đã chuyển sang đoạn từ Thanh Hoá đến Vinh và là 800 xe / 1 giờ (trước khi cải thiện là 100 xe / 1 giờ).
Nếu như chúng ta tăng thêm làn đường mới ở đoạn này thì chắc chắn throughput của toàn bộ hệ thống sẽ tăng lên.
Nhưng chẳng may chúng ta lại đi thêm làn đường ở đoạn mà không phải bottleneck thì sẽ như thế nào?
Chẳng hạn như chúng ta thêm làn đường ở đoạn Thanh Hoá – Vinh để số lương xe lưu thông tăng lên thành 1200 xe / 1 giờ.
Vậy throughput của toàn bộ hệ thống theo các bạn có tăng lên không? Câu trả lời là không nhé.
Vì đoạn ở Vinh – Đà Nẵng vẫn còn đang tắc mà. Số lượng xem lưu thông ở đoạn này có 100 xe. Nên cho dù ở Thanh Hoá – Vinh mà nhiều xe lưu thông đi chăng nữa thì đến đoạn Vinh – Đà Nẵng thì vẫn phải chịu cảnh tắc đường thôi. Nên đoạn này mà không cải thiện thì throughput của hệ thống sẽ không thể tăng được.
Ở ví dụ trên là mình đang nói về vấn đề lưu thông xe trên đường. Nhưng với hệ thống website hiện nay thì hoàn toàn có thể áp dụng được.
Chính vì vậy, để có thể cải thiện được throughput của hệ thống thì điều đầu tiên mình nên làm là tìm ra chính xác đâu là điểm bottleneck.
Cải thiện Latency
Latency là tổng thời gian xử lý của từng bộ phận trong hệ thống, bao gồm cả thời gian đợi.
Để cải thiện được Latency thì chúng ta sẽ đi xem xét xem bộ phận nào xử lý đang chiếm nhiều thời gian nhất thì sẽ đi cải thiện bộ phận đó trước. Sau đó sẽ đi cải thiện các bộ phận tiếp theo.
Nhưng nếu mà thời gian xử lý của từng bộ phận đã nằm trong khoảng thích hợp rồi thì cho dù muốn cải thiện thêm nữa thì cũng không thể được. Tức là nó đã đạt đến ngưỡng rồi ấy.
Ví dụ như với web application, những bộ phận nào đang xử lý chiếm thời gian nhất thì tìm hiểu xem xem thuật toán của nó đã tối ưu chưa, có dùng lãng phí memory không, nếu là DB thì kiểm tra xem đã gắn index chưa …
Để đo xem thời gian chạy của từng chức năng là bao nhiêu, có bao nhiêu lời gọi hàm thì có 1 tool sẽ giúp các bạn làm được điều đó là Profiler.
Ví dụ các bạn đang dùng php thì search google là: Profiling Tools For PHP
Nếu là java thì các bạn cũng search tương tự.
Ví dụ về cải thiện Latency
Quay lại ví dụ ở bên trên, đoạn đường Vinh – Đà Nẵng đang tắc đường. Nên lúc này latency của toàn bộ hệ thống là 18 giờ.
Sau khi giải quyết được vấn đề tắc đường thì latency đã được cải thiện thành 13 giờ.
Thế nhưng nếu chúng ta đi cải thiện nhầm ở đoạn đường mà không xảy ra bottleneck thì mặc dù throughput không được cải thiện nhưng mà latency ít nhiều cũng được cải thiện, vì nó chỉ còn 16 giờ.
Từ đó chúng ta có thể thấy được, so với việc cải thiện throughput thì cải thiện latency sẽ hơi khác 1 chút. Đó là chúng ta chỉ cần cải thiện latency của 1 bộ phận nào đó trong hệ thống cũng kéo theo latency của toàn bộ hệ thống giảm xuống.
Tổng kết
Đọc qua bài này các bạn thấy thế nào ak? Đã nắm rõ được test tải hệ thống là sẽ làm thế nào chưa? Hơi lắm chữ 1 chút nhưng nó khá cần thiết đấy.
Mình hi vọng qua bài này sẽ giúp các bạn có chút hình dung xem việc test tải hệ thống sẽ làm những gì, và để cải thiện hệ thống thì chúng ta nên làm gì.
Bài này mình sẽ chỉ tập trung vào phần lý thuyết thôi nên đọc sẽ hơi mệt nhưng cũng khá dễ hiểu. Có thể bài tới mình sẽ viết 1 bài dạy các bạn cách test tải sẽ như thế nào, dùng tool nào hợp lí, cách tìm bottleneck ra sao.
Viết 1 bài mất nhiều năng lượng quá, cũng giống như các bạn làm việc trên giường ấy. Mà thôi nói đến đây các bạn tự hiểu. 😀
Vì mình mới sử dụng git, nên mình muốn chia sẻ với các bạn một vấn đề mình gặp trong lúc dùng git. Đây là vấn đề cơ bản, nhưng lại tốn thời gian cho những người mới như mình. Bởi vậy, bài viết này là dành cho các bạn mới làm quen với Git như mình. Các pro xin đừng ném đá. Trong bài viết này mình sẽ hướng dẫn các bạn cách tạo SSH Key cho Github trên Window và Ubuntu. Sau đó là config SSH Key này trên Github để mỗi lần thực hiện các thao tác với git (clone, commit, push, pull,..) thì Github không yêu cầu nhập mật khẩu nữa.
Lúc clone một repository trên git về máy của mình, chúng ta sẽ thấy có 2 lựa chọn là Clone with HTTPS và Clone with SSH:
Việc Clone with HTTPS khá đơn giản, git chỉ yêu cầu chúng ta nhập thông tin đăng nhập khi clone, và trong quá trình sau này khi thao tác một số câu lệnh của git nó vẫn tiếp tục yêu cầu chúng ta nhập mật khẩu. Điều này khiến mình cảm thấy hơi phiền lòng. Việc Clone with SSH sẽ giúp ta tránh được nỗi phiền này, song nó lại bắt chúng ta cấu hình trước khi dùng. Vậy là một cái là đau khổ triền miên, cái kia là khổ trước sướng sau. Lúc ban đâu, mình đã thử Clone with SSH như cách mình Clone with HTTPS dĩ nhiên là lúc đó mình chưa cấu hình gì cho SSH Key cả, người mới mà, thì mình nhận được thông báo như sau:
Cuối cùng các bạn hãy clone lại và tận hưởng kết quả đi nhé, từ nay về sau sẽ không còn gặp phiền phức khi git yêu cầu nhập mật khẩu nữa rồi.
Với những bạn không tìm thấy file: github_rsa.pub, hãy làm như sau: 1. Mở cmd với quyền administrator. 2. Chạy câu lệnh:
ssh-keygen -t rsa -C "your_email@example.com"
=>> Thế là các bạn đã tạo xong file github_rsa.pub rồi. Quay lại bước 1 và làm tiếp nhéVới các bạn sử dụng Ubuntu:
Đầu tiên các bạn mở Terminal lên và chạy các lệnh sau:
cd ~/.ssh ls id_* cat < ~/.ssh/id_rsa.pub
Sau khi có ssh-key, các bạn tiến hành cấu hình tiếp tương tự như trên Window (Trường hợp tìm không thấy ssh-key cũng thực hiện tương tự như cách trên window.
Redis là gì? – Redis (REmote DIctionary Server) là một mã nguồn mở được dùng để lưu trữ dữ liệu có cấu trúc, có thể sử dụng như một database, bộ nhớ cache hay một message broker.
Nó là hệ thống lưu trữ dữ liệu với dạng KEY-VALUE rất mạnh mẽ và phổ biến hiện nay. Redis nổi bật bởi việc hỗ trợ nhiều cấu trúc dữ liệu cơ bản như:hash, list, set, sorted set, string… Tất cả dữ liệu được ghi và lưu trên ram, do đó tốc độ đọc ghi dữ liệu rất là nhanh.
Các ứng dụng của Redis
Sau khái niệm redis là gì thì chúng ta hãy đi đến ứng dụng của Redis ngoài tính năng lưu trữ KEY-VALUE trên RAM thì Redis còn hỗ trợ tính năng xắp xếp, query, backup dữ liệu trên đĩa cứng cho phép bạn có thể phục hồi dữ liệu khi hệ thống gặp sự cố…và có thể nhân bản (Chạy nhiều Server Redis cùng lúc).
Caching: Sử dụng làm bộ nhớ đệm. Chính tốc độ đọc ghi nhanh mà Redis có thể làm bộ nhớ đệm, nơi chia sẻ dữ liệu giữa các ứng dụng hoặc làm database tạm thời. Ngoài ra Redis có thể sử dụng để làm Full Page Cache cho website. Cũng vì tính nhất quán của Redis, cho dù restart Redis thì người dùng cũng không có cảm nhận chậm khi tải trang.
Counter: Sử dụng làm bộ đếm. Với thuộc tính tăng giảm thông số rất nhanh trong khi dữ liệu được lưu trên RAM, sets và sorted sets được sử dụng thực hiện đếm lượt view của một website, các bảng xếp hạng trong game chẳng hạng. Redis hỗ trợ thread safe do đó nó có thể đồng bộ dữ liệu giữa các request.
Publish/Suscribe (Pub/Sub): Tạo kênh chia sẻ dữ liệu. Redis hỗ trợ tạo các channel để trao đổi dữ liệu giữa publisher và subscriber giống như channel trong Socket Cluster hay topic trong Apache Kafka. Ví dụ: Pub/Sub được sử dụng theo dõi các kết nối trong mạng xã hội hoặc các hệ thống chat.
Queues: Tạo hàng đợi để xử lý lần lượt các request. Redis cho phép lưu trữ theo list và cung cấp rất nhiều thao tác với các phần tử trong list, vì vậy nó còn được sử dụng như một message queue.
Các kiểu dữ liệu trong Redis
Khác với RDMS như MySQL, hay PostgreSQL, Redis không có table (bảng). Redis lưu trữ data dưới dạng key-value. Thực tế thì memcache cũng làm vậy, nhưng kiểu dữ liệu của memcache bị hạn chế, không đa dạng được như Redis, do đó không hỗ trợ được nhiều thao tác từ phía người dùng. Dưới đây là sơ lược về các kiểu dữ liệu Redis dùng để lưu value.
– STRING: string, integer hoặc float. Redis có thể làm việc với cả string, từng phần của string, cũng như tăng/giảm giá trị của integer, float.
– LIST: List là một danh sách của strings, sắp xếp theo thứ tự insert. Redis có thể thêm một phần tử vào đầu hoặc cuối list. List phù hợp cho các bài toán cần thao tác với các phần tử gần đầu và cuối vì việc truy xuất này là cực nhanh, cho dù insert cả triệu phần tử. Tuy nhiên nhược điểm là việc truy cập vào các phần tử ở giữa list rất chậm.
– SET: tập hợp các string (không được sắp xếp). Redis hỗ trợ các thao tác thêm, đọc, xóa từng phần tử, kiểm tra sự xuất hiện của phần tử trong tập hợp. Ngoài ra Redis còn hỗ trợ các phép toán tập hợp, gồm intersect/union/difference.
– HASH: lưu trữ hash table của các cặp key-value, trong đó key được sắp xếp ngẫu nhiên, không theo thứ tự nào cả. Redis hỗ trợ các thao tác thêm, đọc, xóa từng phần tử, cũng như đọc tất cả giá trị.
– SORTED SET (ZSET): là 1 danh sách, trong đó mỗi phần tử là map của 1 string (member) và 1 floating-point number (score), danh sách được sắp xếp theo score này. Các phần tử của zset được sắp xếp theo thứ tự từ score nhỏ tới lớn.
Ngoài ra, Redis còn hỗ trợ các data types khác như: Bit arrays, HyperLogLogs, Streams. Để cài đặt bạn tham khảo docs của Redis nhé.
Bên cạnh việc lưu key-value trên bộ nhớ RAM, Redis có 2 background threads chuyên làm nhiệm vụ định kỳ ghi dữ liệu lên đĩa cứng.
Có 2 loại file được ghi xuống đĩa cứng:
RDB (Redis DataBase file)
RDB thực hiện tạo và sao lưu snapshot của DB vào ổ cứng sau mỗi khoảng thời gian nhất định.
Ưu điểm
RDB cho phép người dùng lưu các version khác nhau của DB, rất thuận tiện khi có sự cố xảy ra.
Bằng việc lưu trữ data vào 1 file cố định, người dùng có thể dễ dàng chuyển data đến các data centers, máy chủ khác nhau.
RDB giúp tối ưu hóa hiệu năng của Redis. Tiến trình Redis chính sẽ chỉ làm các công việc trên RAM, bao gồm các thao tác cơ bản được yêu cầu từ phía client như thêm/đọc/xóa, trong khi đó 1 tiến trình con sẽ đảm nhiệm các thao tác disk I/O. Cách tổ chức này giúp tối đa hiệu năng của Redis.
Khi restart server, dùng RDB làm việc với lượng data lớn sẽ có tốc độ cao hơn là dùng AOF.
Nhược điểm
RDB không phải là lựa chọn tốt nếu bạn muốn giảm thiểu tối đa nguy cơ mất mát dữ liệu.
Thông thường người dùng sẽ set up để tạo RDB snapshot 5 phút 1 lần (hoặc nhiều hơn). Do vậy, trong trường hợp có sự cố, Redis không thể hoạt động, dữ liệu trong những phút cuối sẽ bị mất.
RDB cần dùng fork() để tạo tiến trình con phục vụ cho thao tác disk I/O. Trong trường hợp dữ liệu quá lớn, quá trình fork() có thể tốn thời gian và server sẽ không thể đáp ứng được request từ client trong vài milisecond hoặc thậm chí là 1 second tùy thuộc vào lượng data và hiệu năng CPU.
AOF (Append Only File)
AOF lưu lại tất cả các thao tác write mà server nhận được, các thao tác này sẽ được chạy lại khi restart server hoặc tái thiết lập dataset ban đầu.
Ưu điểm
Sử dụng AOF sẽ giúp đảm bảo dataset được bền vững hơn so với dùng RDB. Người dùng có thể config để Redis ghi log theo từng câu query hoặc mỗi giây 1 lần.
Redis ghi log AOF theo kiểu thêm vào cuối file sẵn có, do đó tiến trình seek trên file có sẵn là không cần thiết. Ngoài ra, kể cả khi chỉ 1 nửa câu lệnh được ghi trong file log (có thể do ổ đĩa bị full), Redis vẫn có cơ chế quản lý và sửa chữa lối đó (redis-check-aof).
Redis cung cấp tiến trình chạy nền, cho phép ghi lại file AOF khi dung lượng file quá lớn.
Trong khi server vẫn thực hiện thao tác trên file cũ, 1 file hoàn toàn mới được tạo ra với số lượng tối thiểu operation phục vụ cho việc tạo dataset hiện tại. Và 1 khi file mới được ghi xong, Redis sẽ chuyển sang thực hiện thao tác ghi log trên file mới.
Nhược điểm
File AOF thường lớn hơn file RDB với cùng 1 dataset.
AOF có thể chậm hơn RDB tùy theo cách thức thiết lập khoảng thời gian cho việc sao lưu vào ổ cứng. Tuy nhiên, nếu thiết lập log 1 giây 1 lần có thể đạt hiệu năng tương đương với RDB.
Developer của Redis đã từng gặp phải bug với AOF (mặc dù là rất hiếm), đó là lỗi AOF không thể tái tạo lại chính xác dataset khi restart Redis. Lỗi này chưa gặp phải khi làm việc với RDB bao giờ.
Kết luận redis là gì?
Redis là một sự lựa chọn tuyệt vời khi ta cần đến một server lưu trữ dữ liệu đòi hỏi tính mở rộng cao (scaleable) và chia sẻ bởi nhiều tiến trình, nhiều ứng dụng và nhiều server khác nhau.
Composer được ra mắt vào ngày 1/3/2012, và kể từ đó đến nay, Composer được phổ biến rất rộng rãi như là công cụ thiết yếu cho những anh em lập trình PHP.
Trước khi Composer ra đời, chúng ta thường gặp khó với hàng chục các thư viện của bên thứ ba cần phải quản lý. Việc update rất khó khăn và chưa kể các khâu cài đặt rất là khó nhớ. Vớ sự ra đời của Composer đã làm thay đổi hoàn toàn mọi thứ. Trong bài viết này chúng ta sẽ tìm hiểu về Composer – một công cụ quản lý các thư viện trong các project.
Composer là gì?
Composer là một Dependency Management trong PHP, công cụ quản lý các thư viện mà project Php của bạn sử dụng. Một cách chính xác hơn Composer quản lý sự phụ thuộc các tài nguyên trong dự án. Nó cho phép khai báo các thư viện mà dự án của bạn sử dụng, composer sẽ tự động tải code của các thư viện. Nó tạo ra các file cần thiết vào project của bạn, và cập nhật các thư viện khi có phiên bản mới.
Lợi ích của composer
Ý tưởng của composer không phải là mới, nó được lấy cảm hứng từ các công cụ như npm của Node. Phần hoạt động của nó cũng rất giống APT (có trên Ubuntu) hay Yum (có trên CentOS), tuy nhiên composer chỉ ở phạm vi dự án Php chứ không phải trên toàn bộ OS như 2 thằng trên.
Trước đây khi bạn triển khai các dự án dựa trên các, bạn sẽ phải đối mặt một số việc sau:
Dự án của bạn có sử dụng một số thư viện ở ngoài. Bạn phải tải chúng rồi cho vào folder của project rồi mới sử dụng được.
Một số các thư viện đó lại sử dụng (phụ thuộc) các thư viện khác.
Bạn sẽ gặp những khó khăn trong việc cập nhật phiên bản của các thư viện. Nếu thư viện A, có sử dụng thư viện B, thư viện B sử dụng thư viện C. Thì nếu một trong các thư viện này có update, bạn sẽ phải tự mình lần mò về phần gốc của nó để update.
Tuy nhiên, công việc sẽ thật dễ dàng với Composer, bạn sẽ làm được:
Khai báo các thư viện mà dự án sử dụng. Quản lý tập trung các thư viện đang sử dụng cho project và cả phiên bản của chúng dễ dàng qua file composer.json.
Tìm các phiên bản của package có thể cài đặt và cần thiết cho dự án, sau đó cài đặt chúng vào dự án tức là tải chúng về project.
Sử dụng Composer
Để sử dụng composer, ta cần phải có 1 file composer.json. File này chứa thông tin mô tả các dependencies mà ta cần trong project. Nội dung của file có thể là:
Các yêu cầu về dependencies sẽ được liệt kê trong key require. Phía trên là 1 ví dụ cho file composer.json mặc định của laravel framework version 5.8. Phần * nghĩa là ta chấp nhận phiên bản update mới như 5.8.11 hay 5.8.12 chẳng hạn.
Bằng cách sử dụng terminal, trong project folder chúng ta thực hiện lệnh composer install. Nó sẽ tìm trong thư mục hiện có file composer.json và thực hiện các công việc mà file đó yêu cầu bao gồm đưa tất cả dependencies vào project và thực hiện các công việc cần thiết khác.
Autoloading
Trong file chính của project, hãy thêm dòng này vào:
include_once'./vendor/autoload.php';
Tất cả các package bạn cần bây giờ đã được thêm vào project, sẵn sàng cho bạn sử dụng. Hay như trong Laravel bạn chỉ cần đơn giản gõ:
composer dump-autoload
thì tất cả các thư viện trong composer sẵn sàng để sử dụng trong toàn bộ project.
Cập nhật package
Bạn chỉ cần gõ composer update . Composer sẽ tự động cập nhật các package đang sử dụng. Nếu muốn cập nhật lên các phiên bản mới hơn hoặc các bản release, hãy chỉnh sửa file composer.json
Note: Không bao giờ chạy lệnh composer update trong môi trường production mà hãy kiểm tra trên máy để tránh tình trạng không tương thích.
Kết luận
Composer được sử dụng ở mọi nơi trong thế giới PHP, vì vậy đã là một lập trình viên Php bạn cần trang bị thêm kiến thức cơ bản composer. Sau đó thì chúng ta chỉ cần chuyên tâm vào product và gạt bớt suy nghĩ về việc cập nhật package.
Những diễn giả được giới thiệu lần trước có làm bạn hài lòng? Nếu chưa thì chắc chắn các Marketing speaker đợt này sẽ chinh phục những khán giả khó tính nhất.
Let’s have a look:
🔥 Anh Bùi Quang Tinh Tú – CMO Asia – Ringier AG
>>Topic: Martech Trends That You Should Watch Out
Anh Bùi Quang Tinh Tú – CMO Asia của Ringier AG kiêm CEO của Marry Network với kinh nghiệm từng đảm đương nhiều vị trí khác nhau như: Founder của UAN, CMO và là founding member của GO-VIET / GO-JEK VN, Marketing Director của MuaBanNhaDat,… cũng như là diễn giả của các buổi hội thảo lớn.
🔥 Anh Trần Quốc Kỳ – CEO Chin Media
>>Topic: How to Optimize Conversions with Google Analytics (về website)
Thêm một diễn giả với hơn 10 năm kinh nghiệm trong lĩnh vực marketing và truyền thông đó là anh Trần Quốc Kỳ. Anh không những là chuyên gia về Data Analytics, Performance Marketing, Social Ads,..mà còn kinh qua những vị trí quan trọng trong những công ty, tập đoàn lớn như: IDD VIETNAM, Panpages VIETNAM,… Qua nhiều lần làm diễn giả tại các sự kiện lớn về Digital Marketing như: ADdays, DMA, UAN, TOPDEV,….
🔥 Anh Phạm Phước Nguyên – Head of Performance – Biz-eyes / Square Group
>>Topic: 10 Tips for Successful Launch of a Mobile App
Góp mặt trong đội ngũ Marketing Speaker không thể thiếu anh Phạm Phước Nguyên. Một chuyên gia với hơn 9 năm kinh nghiệm trong mảng Sale-Marketing và hơn 7 năm trong lĩnh vực Digital/Performance Marketing tại thị trường Việt Nam và Đông Nam Á.
>>Topic: Mobile App Funnel Optimization with Data Analytics
Chị Lê Ngọc Hạnh – một chuyên gia với hơn 8 năm kinh nghiệm trong lĩnh vực Thương mại Điện tử và Digital Marketing. Trước khi sáng lập PMAX, chị đã có hơn 4 năm kinh nghiệm trong ngành Thương Mại Điện Tử tại Lazada Việt Nam được bổ nhiệm qua nhiều vị trí và lĩnh vực từ Digital marketing cho đến Campaign và Merchandising tại Lazada
🔥 Anh Huỳnh Hữu Tài – Founder of WeTransform
>>Topic: Platform Strategy in Digital Transformation
Anh Huỳnh Hữu Tài với background “khủng” về lĩnh vực công nghệ thông tin-viễn thông (ICT) lẫn dịch thuật là một trong những gương mặt sáng giá trong làng speaker năm nay. Anh là diễn giả về các chủ đề: Chiến lược nền tảng, Cuộc dịch chuyển đại dương xanh…và thường được mời tham gia các event được tổ chức bởi TopDev, FirstNews & BizHub, Alpha Books, Đà Nẵng Co-working Space, Sihub,…
🔥 Anh Lại Tuấn Cường – CEO – Repu Digital
>>Topic: Marketing Automation: Building a Silent Conversion Machine
Anh Lại Tuấn Cường có hơn 13 năm làm việc trên cương vị CEO, Founder, Manager ở nhiều công ty khác nhau như: SocialReach, LinksLead.vn, Young Lim Won SoftLab (Korea),… Để nói về digital marketing thì không thể thiếu anh – “cha đẻ” của Repu Digital – đơn vị Digital Marketing Agency từng tư vấn & triển khai các chiến dịch quảng cáo cho các doanh nghiệp lớn như: Vincom (VinGroup), Tập đoàn Bảo Việt, Bảo Việt Nhân Thọ, Chứng khoán BIDV, NH VPBank, NH PVCombank, Tập đoàn Trung Nguyên, NovaLand, Lotte Cinema.
🔥 Anh Don Ho – Co-founder của Quanstamp
>>Topic: The Future of Blockchain Security and Mass Adoption. The Future of Security Token Offerings.
Anh Don Ho – Co – founder của Quanstamp. Anh quan tâm đến việc gặp gỡ những người sáng lập, doanh nghiệp và nhà đầu tư; cũng như đã xây dựng hệ sinh thái đổi mới về công nghệ ở San Francisco, Los Angeles và Đông Nam Á. Anh sẽ đưa ra những góc nhìn trực quan về Blockchain Security và Mass Adoption tại VMD2019.
🔥 Anh Nguyễn Kim Hưng – Digital Marketing Manager at WeFit.vn
>>Topic: Chiến lược làm Content 2019: công thức marketing giúp phát triển bền vững.
Một chuyên gia digital marketing với kinh nghiệm xây dựng, phát triển và quản lý đội ngũ team Marketing các kênh Digital của sản phẩm tập luyện WeFit sẽ là lựa chọn hoàn hảo cho các nhà marketer muốn tìm hiểu và nắm rõ chiến lược content marketing để phát triển doanh nghiệp.
Bạn đã choáng ngợp với đội ngũ diễn giả của chúng tôi chưa? Còn rất nhiều thông tin mà bạn không muốn bỏ lỡ tại Ngày hội về Công nghệ & Mobile lớn nhất năm nay. Nhanh tay đăng ký và giữ những slots đẹp đẹp cho mình để có cơ hội gặp gỡ các chuyên gia về marketing và technology nào!!!
Tôi không biết chính xác nó là cái gì mà làm cho bao nhiêu developer phát cuồng và lưu trữ session information trong local storage, nhưng dù gì đi nữa: việc này cần phải ngừng lại. Mọi thứ đang dần ngoài tầm kiểm soát.
Gần như ngày nào tôi cũng tình cờ thấy một website mới chứa thông tin nhạy cảm của user trong local storage và tôi cảm thấy rất bối rối khi có quá nhiều developer đang dần gửi gắm hết lên đó.
Hãy cùng ngồi lại, nói về local storage và tại sao bạn nên ngừng sử dụng nó đi.
Local Storage là gì?
Có lẽ với một số người cũng chưa biết local storage là gì nữa. Hãy bắt đầu từ cái căn bản: local storage là một feature mới của HTML5 cho phép bạn lưu trữ bất kì info nào bạn muốn trong browser dùng JavaScript. Nó rất là đơn giản.
Thực tế thì local storage chỉ là một object JavaScript bự và cũ kĩ cho phép bạn attach data (hoặc remove cũng được). Đây là một ví dụ của một vài JavaScript code lưu trữ một vài thông tin cá nhân trong local storage:
// Bạn có thể store local storage sử dụng syntax
localStorage.userName = "TopDev";
localStorage.setItem("favoriteColor", "Red");
// Một khi dữ liệu ở trong Local Storage, nó sẽ ở đó mãi mãi cho đến khi nó được
// explicitly removed
alert(localStorage.userName + " Thích màu " + localStorage.favoriteColor + ".");
Nếu bạn chạy code JavaScript này trong browser trên trang HTML test, bạn sẽ test phrase “TopDev thích màu đỏ” trong alert message. Nếu bạn sử dụng các tool developer của mình, bạn sẽ thấy cả hai biến userName và favoriteColor đều được lưu trữ trong local storage trong browser.
Có thể bạn sẽ thắc mắc liệu có có cách nào data bạn lưu trữ một lúc nào đó tự động xóa và bạn không cần phải xóa từng cái thủ công mỗi biến bạn để vào không. May mắn thay HTML5 working group thêm sessionStorage vào HTML5 hoạt động đúng y như local storage trừ một điểm là tất cả data lưu trữ sẽ tự động xóa đi khi user đóng tab browser lại.
Sau khi hiểu về local storage, chúng ta sẽ bàn về những gì đặc sắc của nó. Mặc dù bài viết này nhằm mục đích thuyết phục bạn từ bỏ local storage, tôi vẫn thừa nhận là nó cũng có vài điểm thú vị.
Đầu tiên: nó là JavaScript thuần! Một trong những thứ gây ức chế nhất về cookies (đặc trưng khác của local storage) đó là nó cần được tạo bởi web server. Nếu bạn đang build một static site (ví dụ như một app đơn trang), việc dùng local storage đồng nghĩa là các web page của bạn có thể chạy độc lập với bất kì web server nào. Chúng không cần ngôn ngữ backend hay logic nào để lưu data trong browser: chúng có thể làm nếu muốn.
Đây là một concept táo bạo và là một trong những lí do chính mà local storage trở nên hot như thế trong giới lập trình.
Một thứ khác tuyệt vời về local storage đó là nó không có nhiều size constraint như cookies. Local storage cung cấp ít nhất 5MB data storage qua tất cả các web browser, hơn nhiều so với cookie (maximum 4KB).
Chính điều này làm cho local storage trở nên hữu ích nếu bạn cache một số app data trong browser để dùng sau. Vì 4kB là không nhiều, local storage là một trong những option thay thế duy nhất.
Local Storage có gì không tốt
Chúng ta đã nói về những cái tốt, bây giờ sẽ chuyển sang cái xấu.
Local storage cực kì basic, API rất đơn giản. Tôi cảm thấy hầu hết các developer không nhận ra nó basic cỡ nào:
Nó chỉ có thể lưu trữ string data. Nó trở nên vô dụng cho việc lưu trữ các loại data phức tạp hơn cho dù chỉ một chút. Và chắc chắn rằng, bạn có thể nhận ra mọi thứ bao gồm các loại data trong local storage, nhưng là một các hack khác ugly.
Nó có đồng bộ. Đồng nghĩa rằng với mỗi local storage operation bạn chạy sẽ chỉ được một lần một lúc.
Các web worker không thể dùng nó. Nó có nghĩa rằng nếu bạn muốn build một app tận dụng background process để tăng hiệu suất, các chrome extension, những thứ như: bạn không thể dùng local storage vì nó không có sẵn cho các web server.
Nó vẫn giới hạn size của data bạn có thể lưu trữ (khoảng 5MB qua các browser). Đây là một khoảng khá hạn hẹp cho những người build app mà có lượng data lớn hoặc cần phải function offline.
Bất kì JavaScript code trên trang của bạn có thể truy cập vào local storage: nó không có cái gì để bảo về data. Một điểm trừ quá lớn về tính bảo mật.
Nói tóm lại, chỉ có duy nhất một trường hợp mà bạn cần dùng local storage: khi bạn cần các info có sẵn mà không quá nhạy cảm, không cần dùng cho các app cao cấp, không quá 5MB, và chỉ chưa string data. Phần 2 sẽ đi sâu vào các phân tích bảo mật và giải đáp cho câu hỏi: Tại sao Local Storage không an toàn và bạn không nên dùng nó để lưu trữ data nhạy cảm?
1 phút quảng cáo: TopDev đang có nhiều công ty quốc tế tuyển JS, Php để đánh global. Anh em ra biển lớn thì đừng ngại xem qua nhé. Link tại đây: https://topdev.vn/viec-lam-it
Chắc hẳn ai trong số chúng ta cũng đã từng dùng 1 số dịch vụ thiết kế URL Shortening (rút gọn link) như Bit.ly hay TinyURL.
Đối với 1 software engineer thì việc dùng là 1 chuyện, nhưng làm thế nào để thiết kế được 1 hệ thống chịu tải hàng tỉ click mỗi tháng chắc hẳn cũng nhiều người quan tâm.
Hôm nay mình viết bài này để đào sâu vào những hệ thống đó xem họ đã thiết kế như thế nào nhé.
Mục tiêu của bài viết
Sẽ giúp các bạn có cái nhìn tổng quan về cách thiết kế hệ thống hàng triệu người dùng, hàng tỉ click mỗi tháng nó như thế nào. Từ cách tư duy đến cách tiếp cận bài toán.
Có thể tự mình xây dựng được 1 hệ thống URL Shortening giống Bitly, TinyURL.
Giúp các bạn có kinh nghiệm đi phỏng vấn vào vị trí system design.
Hệ thống URL Shortening là gì?
Chắc hẳn cũng có 1 số bạn chưa từng dùng dịch vụ rút gọn link bao giờ. Vậy để mình giải thích ngắn gọn xem URL Shortening là gì đã nhé.
URL Shortening (rút gọn link) là 1 dịch vụ giúp chúng ta có thể làm ngắn link gốc lại được.
Bây giờ nếu chúng ta mở link http://bit.ly/2VXBAw4 ở trình duyệt thì nó sẽ chuyển hướng đến link gốc.
Tại sao cần dùng rút gọn link?
Đây chắc hẳn là câu hỏi mà nhiều người quan tâm. Ví dụ như: cứ gửi link gốc cho người xem chứ cần gì phải rút gọn link làm gì cho nó mất thời gian? Rồi bây giờ có ai phải tự nhập link bằng tay nữa đâu mà phải làm mất công? …
Công nhận những thắc mắc đó của mọi người không sai.
Mục đích chính của việc dùng rút gọn link là:
Nhìn link ngắn gọn trông đẹp mắt hơn.
Có thể thống kê lượng người click vào link để phân tích, đánh giá kết quả. Phục vụ cho marketing.
Có thể ẩn 1 số link tiếp thị liên kết với mục đích là kiếm tiền.
Yêu cầu về mặt chức năng hệ thống
Hầu hết các hệ thống rút gọn link phải đáp ứng được những yêu cầu sau:
Yêu cầu về mặt chức năng:
Đầu vào là 1 link gốc, hệ thống sẽ rút gọn link gốc đó thành 1 dạng link ngắn hơn và duy nhất
Khi người dùng access vào link rút gọn, hệ thống sẽ chuyển nó đến link gốc
Người dùng có thể lựa chọn customize link rút gọn của mình theo ý muốn.
Link rút gọn sẽ hết hạn sau 1 khoảng thời gian mặc định nào đó. Tuy nhiên người dùng có thể điều chỉnh cái khoảng thời gian này.
Yêu cầu phi chức năng:
Hệ thống có tính available (sẵn sàng) cao. Vì sao phải cần cái này? Vì nếu hệ thống die thì toàn bộ link rút gọn lúc đó cũng die theo.
Khi click vào link rút gọn để chuyển sang link gốc, thì thời gian redirection đó phải tối thiểu (minimal latency).
Link rút gọn không thể đoán được.
Yêu cầu mở rộng:
Có thể phân tích được bao nhiêu lần click vào link rút gọn?
Cung cấp API cho bên thứ 3 có thể dùng được.
Phân tích hệ thống
Ở phần này mình sẽ trình bày cho các bạn cách ước lượng số lượng request hàng tháng, dung lượng disk, dung lượng memory cần dùng, băng thông mạng tiêu tốn là bao nhiêu …
Đa số những hệ thống rút gọn link này sẽ có lượng access khá là cao.
Giả sử như hệ thống chúng ta thiết kế sẽ có tỉ lệ read:write là 100:1. (Các bạn nhớ tỉ lệ này nhé vì nó dùng trong suốt bài viết)
Trong đó:
tỉ lệ read ở đây tức là số lượng người click vào link rút gọn
tỉ lệ write là số người tạo ra link rút gọn.
Ước lượng traffic
Giả sử như hệ thống của chúng ta có 500 triệu link rút gọn trong 1 tháng.
Với tỉ lệ read:write là 100:1 thì khi đó số lượng read sẽ là: 500M * 100 = 50B (M là milion, B là bilion)
200 * 100 = 20K URL/s (vì tỉ lệ read:write là 100:1)
Ước lượng storage
Giả sử như chúng ta sẽ lưu tất cả link rút gọn trong 5 năm.
Do chúng ta có 500M link rút gọn trong 1 tháng, khi đó 5 năm chúng ta sẽ có:
500M * 12 months * 5 years = 30B URLs
Giả sử mỗi 1 link rút gọn chúng ta sẽ dùng mất 500 bytes để lưu nó trong storage. Dung lượng ổ đĩa lưu 500M URL trong 5 năm sẽ là:
30B * 500 bytes = 15TB
Ước lượng bandwith (băng thông mạng)
Trước tiên mình giải thích qua về bandwith (băng thông mạng) là gì.
Băng thông mạng là thuật ngữ chỉ lượng truyền dữ liệu (data size) trong khoảng thời gian 1 giây.
Trong đó lượng truyền dữ liệu sẽ bao gồm 2 loại là incoming data với outgoing data:
incoming data là lượng dữ liệu truyền đến server (giống như kiểu upload ấy)
outgoing data là lượng dữ liệu từ server trả về cho người dùng (giống như download)
Vì hệ thống của chúng ta có 200 URL mới trong 1 giây thì khi đó:
total incoming data = 200 * 500 bytes = 100 KB/s
Với read request thì hệ thống của chúng ta có 20K URL/s thì khi đó:
total outgoing data = 20K * 500 bytes = 10MB/s
Ước lượng memory
Để hệ thống có thể chạy nhanh hơn thì giải pháp tốt nhất đó là cache lại những cái link rút gọn nào mà có nhiều người dùng click.
Vậy chúng ta sẽ cần bao nhiêu memory?
Nếu chúng ta đi theo quy tắc 80:20 nghĩa là 20% số lượng link rút gọn tạo ra 80% traffic hệ thống. (Hiểu đơn giản là chỉ có 20% số lượng link rút gọn là nhiều người dùng access, còn lại 80% ko có ai access cả. Nên 20% link rút gọn sẽ tạo ra 80% traffic là vì lí do đó).
Vì chúng ta có tổng cộng 20K URL/s (hay 20K requests/s) thì khi đó 1 ngày sẽ có:
20K * 3600 seconds * 24 hours = 1.7B request/day
Để cache được 20% số request này thì chúng ta sẽ cần:
0.2 * 1.7B * 500 bytes = 170GB memory
Tóm tắt lại kích thước hệ thống
Hệ thống của chúng ta có 500M URL trong 1 tháng, và có tỉ lệ read:write là 100:1. Khi đó đặc tả về hệ thống của chúng ta sẽ như sau:
200 URL được tạo ra mỗi giây
Số lượng access: 20K request/s
Incoming data (giống như upload): 100KB/s
Outgoing data (giống như download): 10MB/s
Dung lượng ổ đĩa trong 5 năm: 15TB
Dung lượng memory dùng cho cache: 170GB
Thiết kế API
Chúng ta có thể dùng SOAP hoặc là REST APIs để thiết kế API của hệ thống. Xem thêm RESTful API là gì?
Qua những yêu cầu ở bên trên, thì ta thấy hệ thống của chúng ta ít nhất cần 2 api sau:
api_dev_key (string): là API developer key của người dùng đã đăng kí tài khoản. Key này được sử dụng để định danh người dùng, giới hạn số lượng request của người dùng (hay còn gọi là rate-limiting)
original_url (string): link gốc
custom_alias (string – optional): customize key cho URL
expire_date (string – optional): ngày hết hạn của link rút gọn
Giá trị trả về (string):
Nếu thành công sẽ insert vào trong cơ sở dữ liệu và trả về link rút gọn
Nếu thất bại sẽ trả về error code.
deleteURL
API thứ 2 cũng khá cần thiết đó là xoá đi link rút gọn đã đăng kí.
deleteURL(api_dev_key, url_key)
Trong đó:
api_dev_key (string) là API developer key của người dùng đã đăng kí tài khoản
url_key (string): là link rút gọn.
Giá trị trả về (string):
Nếu thành công sẽ trả về link rút gọn đã bị xoá.
Nếu thất bại sẽ trả về error code.
Làm thế nào ngăn chặn hacker?
Hacker có thể dùng api để tạo ra thât nhiều link rút gọn vượt quá thiết kế hệ thống hiện tại. Với mục đích cho hệ thống của chúng ta “đắp chiếu luôn”.
Ví dụ như hệ thống hiện tại của chúng ta đang thiết kế đáp ứng 1 tháng 500 triệu URL được tạo ra.
Và hacker tấn công sẽ tạo gấp 100 lần hiện tại là khoảng 50 nghìn tỉ URL để hệ thống sẽ tiêu thụ nhiều tài nguyên hơn, dùng nhiều memory hơn, tốn nhiều ổ đĩa hơn. Khi đó chắc chắn hệ thống sẽ bị down. Và toàn bộ link rút gọn sẽ bị tan biến.
Vậy làm thế nào để giải quyết đc bài toán này? Cách đơn giản nhất là sẽ hạn chế số lần call api thông qua api_dev_key (kĩ thuật này được gọi là kỹ thuât rate-limiting mà Grab sử dụng). Ví dụ như mỗi api_dev_key sẽ chỉ cho tạo tầm 100 link rút gọn trong 1 ngày chẳng hạn.
Tuy không phải là cách hoàn hảo 100% nhưng ít nhiều cũng hạn chế được 1 số vấn đề.
Thiết kế database
Yêu cầu về database của chúng ta sẽ như sau:
Cần lưu hàng tỉ record
Mỗi 1 object sẽ lưu càng nhỏ càng tốt (tầm dưới 1KB)
Không cần mối quan hệ dữ liệu giữa các record.
Hệ thống có tỉ lệ read khá cao
Database schema:
Chúng ta sẽ cần 2 bảng chính: 1 bảng lưu thông tin người dùng, và 1 bảng lưu thông tin về URL.
Loại Database nào nên sử dụng?
Vì chúng ta đã dự đoán trước là sẽ lưu đến hàng tỉ record, hơn nữa các bảng không có mối quan hệ nào với nhau cả nên việc dùng loại NoSQL key-value có lẽ sẽ là lựa chọn tốt nhất. Ví dụ như DynamoDB, Cassandra mình thấy đều ok cả. Xem thêm so sánh SQL và NoSQL.
Thuật toán và thiết kế hệ thống cơ bản
Vấn đề cần giải quyết ở đây là làm thế nào có thể tạo ra được 1 link rút gọn và nó duy nhất từ 1 link gốc.
Thì phần này chúng ta sẽ đi thiết kể để tạo ra được phần rút gọn, chính là 2VXBAw4.
Encoding URL
Chúng ta có thể sử dụng 1 số hàm băm (như MD5 hay SHA256) để băm giá trị đầu vào URL. Sau đó sẽ dùng 1 số hàm mã hoá để hiển thị. Ví dụ như base36 ([a-z, 0-9]), hoặc base62 ([a-z, A-Z, 0-9]) và base64 ([a-z, A-A, 0-9, -, .]).
1 câu hỏi được đặt ra ở đây là chúng ta sẽ dùng độ dài key là bao nhiêu? 6,8 hay là 10?
Nếu dùng base64 cho 6 kí tự thì tổng chúng ta có 64^6 = 68.7B URL
Nếu dùng base64 cho 8 kí tự thì tổng chúng ta có 64^8 = 281 nghìn tỉ URL
Do hệ thống của chúng ta có 500M URL được tạo ra mỗi tháng, hệ thống dùng trong 5 năm sẽ có tổng:
500M * 12 months * 5 = 30B URLs / 5 years.
Do đó với 68.7B URL (với 6 kí tự) là có thể dùng được trong 5 năm rồi.
Nếu chúng ta dùng thuật toán MD5 như hàm băm, thì khi đó nó sẽ tạo ra giá trị hash có chứa 128 bit. Sau đó base64 để encode giá trị băm, nó sẽ tạo ra ít nhất 21 kí tự (vì mỗi kí tự base64 sẽ encode 6 bits giá trị hash).
Trong khi đó không gian khoá của chúng ta chỉ cần 6 kí tự thôi. Vậy làm thế nào có thể chọn ra khoá? Chúng ta có thể chọn ra 6 kí tự đầu tiên cũng được. Mặc dù có trường hợp nó trùng nhau. nhưng mà xác suất chỉ tầm 1/(64^6). Nó rất là nhỏ. Nên có thể chấp nhận được.
Nếu an toàn thì mỗi lần generate ra thì sẽ check trong DB xem có hay chưa? Nếu chưa có thì ok, còn nếu có rồi thì sẽ thêm xâu random nào vào trước URL và lại lặp lại cho đến khi sinh ra unique thì thôi.
※ Cách lấy 6 kí tự đầu tiên này chỉ là 1 giải pháp thôi nhé. Các bạn có thể tự cài đặt cho mình thuật toán khác, miễn nó sinh ra được 6 kí tự unique là được.
Đây là 1 ví dụ về trường hợp lấy 6 kí tự đầu tiên:
Nhiều người dùng có thể cùng dùng chung 1 link gốc, do đó link rút gọn sẽ bị trùng lặp. Và điều này không thể chấp nhận được.
Điều gì sẽ xảy ra nếu như 1 phần nào đó trong URL bị mã hoá. Ví dụ như http://example.com/index.php?id=design và http://example.com/index.php%3Fid%3Ddesign là 2 URL hoàn toàn giống nhau nhưng mà 1 phần URL đã bị mã hoá.
Giải quyết vấn đề trên như thế nào?
Có 2 cách tiếp cận có thể giải quyết được vấn đề này.
Chúng ta có thể sử dụng 1 số nguyên tăng dần và gắn vào đầu mỗi link gốc. Khi đó nó sẽ luôn đảm bảo link gốc của chúng ta là duy nhất, kể cả có nhiều người cùng điền vào 1 link duy nhất đi chăng nữa thì link rút gọn sẽ luôn khác nhau. Và sau khi tạo xong link rút gọn thì số nguyên này sẽ tăng thêm 1. Nhưng mà có 1 vấn đề là nếu tăng mãi thì có thể số nguyên này sẽ bị tràn số. Hơn nữa việc xử lý tăng dần này cũng ảnh hưởng đến hiệu suất của hệ thống.
Cách khác là chúng ta có thể thêm user_id vào đầu mỗi URL. Tuy nhiên nếu người dùng chưa đăng nhập mà muốn tạo link rút gọn, khi đó chúng ta phải yêu cầu nhập vào 1 khoá nữa. Và khoá này phải duy nhất (Nếu khoá nhập vào không duy nhất sẽ yêu cầu nhập lại, đến khi nào duy nhất thì thôi).
Và dưới đây sẽ là flow của hệ thống:
Đầu tiên người dùng nhập link muốn rút gọn, và ấn Enter. Khi đó request sẽ được gửi đến Server.
Ở Server sẽ nhận request và chuyển nó đến bộ phận chuyên xử lý việc rút gọn link. Mình gọi đó là Encoding Service đi.
Encoding Service sẽ thực hiện xử lý rút gọn URL.
Nếu như URL đó chưa tồn tại trong hệ thống thì sẽ xử lý, lưu link đã rút gọn vào trong database đồng thời trả về cho server kết quả.
Nếu như URL đó đã tồn tại trong hệ thống (tức là có ai đó đã sử dụng URL này rồi). Thì khi đó nó sẽ thêm 1 sequence (số nguyên tăng dần) vào đầu URL và thực hiện rút gọn link. Sau đó lưu link đã rút gọn vào trong database đồng thời trả kết qủa về cho server.
Phía Server nhận kết quả và sẽ trả về cho người dùng.
Data Partitioning and Replication
Nếu chúng ta lưu tất cả 30 tỉ URL vào trong DB, và có tới 20K request/s call vào DB. Thì khi đó có thể DB sẽ chịu tải khá lớn và dẫn đến down. Để giải quyết vấn đề này thì có 2 giải pháp:
Phân vùng dữ liệu trong database (Data Partitioning). Tức là chúng ta sẽ tách DB ra thành nhiều con DB khác nhau. Mỗi con sẽ chứa 1 phần dữ liệu.
Cache lại URL nào mà hay gọi để giảm thiểu query đến DB (mình sẽ giải thích cái này trong phần tiếp theo)
Đối với Data Partitioning thì sẽ có 2 loại:
Range Based Partitioning
Loại phân vùng này sẽ dựa vào chữ cái đầu tiên trong URL hoặc hash key để phân chia dữ liệu.
Ví dụ như những URL (bỏ qua phần https:// hay http://) mà bắt đầu bằng từ “a” thì sẽ cho vào DB loại “a”. Những URL nào bắt đầu bằng chữ “b” sẽ cho vào trong database loại “b”.
Nếu như phân vùng dựa vào chữ cái đầu tiên này thì chúng ta sẽ cần 26 con database khác nhau (từ a -> z)
Nhưng mà giải pháp này có thể gặp vấn đề là giả sử chúng ta cho tất cả URL bắt đầu bằng chữ “f” vào trong database loại “f”. Nhưng chẳng may tất cả URL bắt đầu bằng chữ “f” này lại là những URL có access lớn nhất. Khi đó con DB loại “f” này lại chịu tải khá lớn.
Chú ý: Kiểu phân vùng dựa vào chữ cái đầu tiên này chỉ là 1 ví dụ thôi nhé, các bạn có thể tự nghĩ ra thuật toán riêng cho mình để phân vùng dữ liệu cho hợp lí và hiệu quả. Chứ không nhất thiết cứ phải chọn chữ cái đầu tiên để phân vùng.
Hash-Based Partitioning
Loại này chúng ta sẽ lấy giá trị hash của object đang được lưu trữ. Sau đó sẽ tính toán xem phân vùng nào sẽ được xử dụng dựa vào hàm băm. Chúng ta có thể lấy giá trị hash của primary key, hoặc là link gốc để xác định xem phân vùng nào sẽ được lưu trữ dữ liệu.
Cache
Đối với hệ thống hàng tỉ click mỗi tháng thì cache server là thứ không thể thiếu được.
Lí do tại sao chúng ta cần 1 cache server?
Flow chuẩn sẽ là:
Bước 1: người dùng accees đến link rút gọn
Bước 2: chúng ta phải vào DB để lấy ra link gốc từ link rút gọn
Bước 3: chuyển hướng người dùng đến link gốc.
Nếu không có cache server thì cứ mỗi lần như vậy sẽ phải vào trong DB để lấy kết quả. Và dẫn đến DB sẽ phải chịu tải khá lớn. Để giảm thiểu query đến DB, chúng ta sẽ cache lại kết quả truy vấn trước đó. Để từ lần sau nếu người dùng có truy cập vào link rút gọn thì lúc này chúng ta chỉ cần vào cache lấy ra là xong, mà không phải query vào DB để lấy kết quả nữa.
Vì Cache Server sẽ luôn lưu dữ liệu trên memory. Nên so với việc lấy kết quả từ DB thì việc lấy kết quả từ memory sẽ nhanh hơn rất nhiều lần.
Chúng ta cần dùng Cache Server nào?
Hiện nay thì có rất nhiều cache server như Redis, Memcache. Mình thấy nó khá nổi tiếng và cũng đang được dùng khá rộng rãi trên các hệ thống lớn trên thế giới.
Trước mình làm công ty về Game và hệ thống bên mình lúc đó dùng Redis và mình thấy nó khá ổn và support rất nhiều chức năng. Ví dụ như tự động xếp hạng ranking kết quả, có thể sync dữ liệu giữa memory và storage để phòng tránh mất dữ liệu…
Nên nếu bạn nào chưa biết nên dùng cái nào thì mình khuyên nên tìm hiểu và implement thằng Redis này.
Chúng ta cần bao nhiêu GB memory?
Như phần trước mình đã tính toán là hệ thống này sẽ dùng đến 170GB memory để cache 20% URL. Mà hiện nay server có 256GB memory cũng khá nhiều nên thừa sức giải quyết vấn đề này.
Ngoài ra chúng ta có thể tổ hợp nhiều server nhỏ (mỗi server có 8GB memory chẳng hạn) để cache các URL đó lại cũng được cả.
Nếu cache full thì làm thế nào?
Đa số hệ thống cache đều thực hiện theo 1 số cơ chế như LRU (Least Recently Used) hay LFU (Least Frequently Used).
LRU (Least Recently Used): bỏ đi các item trong cache ít được dùng gần đây nhất.
LFU (Least Frequently Used): bỏ đi các item trong cache ít được sử dụng nhất.
Do có các cơ chế này nên cache sẽ luôn được làm mới để tránh việc dùng full.
Cơ chế hoạt động của Cache Server:
Mình sẽ giải thích qua về cơ chế của Cache Server nhé:
Đầu tiên người dùng access đến link rút gọn.
Khi đó, application server sẽ check xem có kết quả ở trong cache không?
Nếu kết quả không có trong cache, thì nó sẽ thực hiện truy vấn đến DB để lấy kết quả và trả về cho người dùng. Đồng thời update kết quả vào trong cache để phục vụ cho lần sau.
Nếu kết quả có trong cache thì sẽ lấy luôn kết quả và trả về cho người dùng.
Các bạn thấy cơ chế khá đơn giản phải không nào.
Load Balancer
Với hệ thống nhiều access như hệ thống này thì 1 web server chưa chắc đã chịu tải được. Để giải quyết bài toán này thì mình sẽ dùng nhiều web server. Mỗi web server sẽ chịu 1 phần request từ người dùng. Xem thêm Web Server là gì?
Câu hỏi đặt ra là làm thế nào có thể tự động phân request đến từng con web server khác nhau?
Và Load Balancer đã ra đời để giải quyết vấn đề này.
Ví dụ như dưới Load Balancer có 1 số con web server. Lần 1 request từ Client gửi đến Load Balancer sẽ được forward đến con web server 1. Lần 2 sẽ được gửi đến con web server 2 ….
Hiện nay 1 số nhà cung cấp server như AWS, Google hay Azure đều support Load Balancer cả. Nên các bạn không cần phải lo lắng về việc phải build 1 con load balancer. Chỉ việc cài đặt và dùng là xong.
Kiến trúc toàn bộ hệ thống
Sau khi đã hiểu qua hết các thành phần thì mình tổng hợp lại kiến trúc tổng thể của hệ thống như sau:
Kết luận
Đọc qua bài này chắc hẳn các bạn cũng có 1 chút tư duy trong việc thiết kế hệ thống lớn phục vụ hàng triệu người dùng nó như thế nào rồi phải không?
Sau khi đã có tư duy rồi thì mình nghĩ nếu gặp phải 1 hệ thống tương tự như thế thì các bạn cũng thừa sức để giải quyết. Nếu gặp khách hàng thì có thể chém ra bão ra gió được.
Vì nhiều bạn mới ra trường hay những bạn chưa từng làm trong các hệ thống lớn chắc chưa hình dung được nên bắt đầu từ đâu, nên sử dụng công nghệ nào. Thì qua bài này hy vọng sẽ giúp các bạn giải đáp những thắc mắc đó.
Học Machine learning (ML)!!! nghe có vẻ là nhiệm vụ bất khả thi, đặc biệt là khi bạn học sai cách.
Tuy nhiên, sau khi dành trọn 1 tuần để học những thức căn bản của ML, mình nhận thấy nó dễ tiếp cận hơn nhiều so với những gì mình tưởng tượng.
Trong bài viết này mình sẽ giới thiệu các bạn một lộ trình bắt đầu học ML như thế nào từ những kinh nghiệm thực tế trong tuần đầu mình học.
Background cần có
Trước khi mình học ML, mình đã đọc trước về nó một chút, và có tham gia một nửa khoá học của Andrew Ng trên Coursera và một vài khoá học lý thuyết khác. Nhờ vậy mà mình có được một ít kiến thức về ML, nhưng mình vẫn không thể dùng mớ kiến thức đó để viết code, cũng như ứng dụng thực tiễn. Và mình muốn thay đổi việc này.
Mình muốn có khả năng giải quyết vấn đề với ML vào cuối tuần học đó, mặc cho việc bỏ qua rất nhiều nguyên tắc cơ bản, và phải tiếp cận theo hướng từ trên xuống dưới, thay vì từ dưới đi lên.
Sau khi tham khảo trên Hacker News, mình đi đến kết luận rằng module Scikit Learn của Python là điểm xuất phát tuyệt vời nhất. Module này cung cấp cho bạn rất nhiều thuật toán machine learning để lựa chọn, đưa việc học máy thực tế xuống chỉ còn một vài dòng code.
Ngày Thứ 2: Học một số thứ thực tế
Mình bắt đầu tuần học bằng cách tìm kiếm video tutorial về Scikit Learn. Cuối cùng mình cũng tìm được tutotial của Sentdex về cách sử dụng ML để đầu tư cổ phiếu, tutorial này cung cấp cho mình một số kiến thức cấn thiết để chuyển sang bước tiếp theo.
Ưu điểm của tutorial của Sentdex là người hướng dẫn giới thiệu bạn toàn bộ các bước thu thập data. Khi bạn xem hết, bạn sẽ nhận ra việc tìm nạp và dọn dẹp data có thể tốn nhiều thời gian hơn cả việc học máy thực sự. Vậy nên kỹ năng viết script để scrape data từ các file hoặc crawl trên web là những kỹ năng cần thiết cho những người đam mê ML.
Mình cũng phải xem lại một số video mỗi khi gặp vấn đề, và mình nghĩ các bạn cũng nên như thế.
Tuy nhiên, nếu bạn đã biết cách scrape data từ website, tutorial này có lẽ sẽ không phù hợp với bạn vì có nhiều video cũng nói về tìm nạp dữ liệu rồi. Trong trường hợp đó, Intro to Machine Learning của Udacity sẽ là nơi xuất phát tốt nhất dành cho bạn.
Vào ngày thứ 3, mình muốn thử xem là mình đã có thể sử dụng những kiến thức vừa học để giải quyết một vấn đề thực tế chưa. Có 1 lập trình viên khác trong team code của mình đang tham gia cuộc thi data visualization của Ngân hàng Anh, mình cùng anh ta kiểm tra bộ dữ liệu mà ngân hàng công bố. Data thú vị nhất chính là các khảo sát hộ gia đình của họ. Đây là một khảo sát hàng năm mà ngân hàng thực hiện trên một vài nghìn hộ gia đình có liên quan đến tiền.
Vấn đề mà chúng mình phải giải quyết là: “Với thông tin về trình độ học vấn, tuổi tác và thu nhập của một người, máy tính có thể dự đoán được giới tính của người đó không?”
Mình lượn một vòng quanh bộ dữ liệu, dành một vài giờ clean data, và sử dụng Scikit Learn map để tìm thuật toán phù hợp cho vấn đề trên.
Cuối cùng bọn mình có được tỉ lệ thành công là 63%, cũng không ấn tượng là mấy. Nhưng ít nhất thì máy tính cũng đã có thể dự đoán tốt hơn một chút so với tỉ lệ 50% của việc tung đồng xu.
Xem kết quả giống như tự tạo động lực cho bản thân, nên mình khuyên các bạn hãy tự làm giống mình khi đã biết sơ cách sử dụng Scikit Learn nhé.
Và đó cũng là khoảnh khắc bạn nhận ra bạn có thể sử dụng ML để giải quyết các vấn đề thực tế trong cuộc sống.
Ngày thứ 4: Học lên tiếp
Sau khi mần đủ các module Scikit Learn, mình quyết định thử viết một thuật toán hồi quy tuyến tính mặc dù chưa biết gì. Mình muốn làm điều này bởi vì mình cảm thấy là mình không thể thực sự hiểu được nếu không thực hành.
May mắn là vào thời điểm này mình tìm đươc khoá học Coursera có dạy chi tiết về cách một vài thuật toán làm việc. Cụ thể hơn, nó mô tả khái niệm cơ bản về việc sử dụng linear regression với gradient descent
Đây hoàn toàn là kỹ thuật hiệu quả nhất, vì nó giúp bạn hiểu được các bước từ đầu đến cuối. Mình cực kì khuyến khích các bạn nên làm thử.
Mình dự định viết lại cách triển khai của mình đối với các thuật toán phức tạp hơn khi mình thực hành, nhưng mình thích làm việc này sau khi mình đã “ngâm” hết các thuật toán tương ứng trong Scikit Learn hơn.
Ngày thứ 5: Đi thi thố
Vào ngày thứ 5, mình bắt đầu làm bài hướng dẫn giới thiệu của Kaggle. Kaggle là một platform dành cho các cuộc thi ML, nơi bạn có thể gửi các giải pháp cho các vấn đề mà công ty hay tổ chức nào đó đưa lên.
Mình khuyên bạn nên thử Kaggle sau khi có một ít thuật toán và kiến thức thực tế về Machine Learning để bắt đầu với nó. Nếu không thì lại chuyển từ có ích sang bực bội mà thôi.
Tutorial của Bag of Words hướng dẫn bạn từng bước tham gia bài dự thi, và cung cấp cho bạn một bản giới thiệu ngắn gọn và thú bị về Natural Language Processing (NLP). Mình thấy hứng thú với NLP hơn nhiều khi coi xong tutorial này.
Ngày thứ 6: Trở lại trường
Mình tiếp tục làm việc với những tutorial của Kaggle vào ngày thứ 6, và cũng bắt đầu dùng Intro to Machine Learning của Udacity. Mình đã đi được nửa chặng đường và mọi thứ khá thú vị.
Nó dễ hơn khoá học Coursera nhiều, vì nó không đào sâu vào các thuật toán. Nó cũng thực tế hơn, vì nó dạy Scikit Learn giúp việc áp dụng vào thực tế dễ hơn nhiều so với viết thuật toán trong Octave khi bạn học Coursera.
1 tuần vừa rồi rất vui với mình, mình nhận thấy được sự hữu ích của ML trong xã hội. Càng tìm hiểu, mình càng thấy nó có thể sử dụng để giải quyết mọi vấn đề.
Nếu bạn hứng thú với machine learning, mình mạnh dạng khuyên bạn nên dành một vài ngày hoặc vài buổi tối để đắm chìm với nó.
Chọn cách tiếp cận từ trên xuống nếu bạn không sẵn sàng học nhiều thứ nặng nề và muốn giải quyết các vấn đề nhanh nhất có thể.
Marketer, Business owner, Designer, Engineer hay là Freelancer thì việc cập nhật và ứng dụng các yếu tố công nghệ sẽ là điều xếp hạng thứ 3 chỉ sau kỹ năng và kiến thức khiến bạn trở thành master trong lĩnh vực của mình.
Cạnh tranh khoa học và công nghệ không thể thiếu cập nhật, công nghệ di động ngày càng lên ngôi và thành công vẫn còn tiếp diễn, một khi doanh bạn đã “dấn thân” vào cuộc chiến thì điều tất yếu là nên biết xung quanh bạn đang diễn ra điều gì?
Vietnam Mobile Day 2019 trở lại, đại hội công nghệ lĩnh vực di động lớn nhất trong năm sẽ trở thành một sân chơi không thể thiếu cho những anh tài cùng nhau chia sẻ những bí kíp, xu hướng, công nghệ đang lên trong ngành di động. Hé lộ nhóm speaker đầu tiên đều là những “lão làng” trong lĩnh Marketing và Technology của chương trình:
Vietnam Mobile Day năm thứ 9 sẽ được đầu tư từ quy mô đến chất lượng, với nội dung xoay quanh 6 nhóm chủ đề chính với hơn 100+ nội dung được trình bày, đó là:
Digital Transformation & Mobilization
Woman in Tech
5G & Internet of things, Machine Intelligence and future of Mobile Technology
Fin-Tech/ Mobile Payment/Ecommerce & Mobile commerce
Digital Marketing & Mobile Marketing
Mobile content (AR/VR/Livestream) and gaming
Dù bạn là dev, marketer hay là những doanh nghiệp về công nghệ mong muốn phát triển hơn trong tương lai, đây chính là sân chơi dành riêng cho bạn!!
Vấn đề bảo mật website có thể nói là rất quan trọng. CSRF là một kiểu tấn công diễn ra khá phổ biến hiện nay trên các website không bảo mật. Nếu bạn là một lập trình viên thì cần nắm rõ kiểu tấn công này để đảm bảo tính bảo mật cho ứng dụng web của mình.
Vậy CSRF là gì?
CSRF hay còn gọi là kỹ thuật tấn công “Cross-site Request Forgery“, nghĩa là kỹ thuật tấn công giả mạo chính chủ thể của nó. CSRF nói đến việc tấn công vào chứng thực request trên web thông qua việc sử dụng Cookies. Đây là nơi mà các hacker có khả năng sử dụng thủ thuật để tạo request mà bạn không hề biết. Vì vậy, một CSRF là hacker lạm dụng sự tin tưởng của một ứng dụng web trên trình duyệt của nạn nhân.
Cách thức hoạt động
CSRF là một kiểu tấn công gây sự nhầm lẫn tăng tính xác thực và cấp quyền của nạn nhân khi gửi một request giả mạo đến máy chủ. Vì thế một lỗ hổng CSRF ảnh hưởng đến các quyền của người dùng ví dụ như quản trị viên, kết quả là chúng truy cập được đầy đủ quyền.
Khi gửi một request HTTP, trình duyệt của nạn nhân sẽ nhận về Cookie. Các cookie thường được dùng để lưu trữ một session (Đọc thêm bài Session là gì? để hiểu thêm cách hoạt động của Session và cookies) để định danh người dùng không phải xác thực lại cho mỗi yêu cầu gửi lên.
Nếu phiên làm việc đã xác thực của nạn nhân được lưu trữ trong một Cookie vẫn còn hiệu lực, và nếu ứng dụng không bảo mật dễ bị tấn công CSRF. Kẻ tấn công có thể thử dụng CSRF để chạy bất cứ requets nào với ứng dụng web mà ngay cả trang web không thể phân biệt được request nào là thực hay giả mạo.
Ví dụ để hiểu rõ hơn, khi ứng dụng web có một chức năng đơn giản đó là thay đổi mật khẩu người dùng. Việc gửi lên server theo phương thức HTTP GET thông thường. Nội dung gửi lên là password mới và confirm lại password vừa nhập:
Người dùng đã đăng nhập trên web của bạn, cookie sẽ được tạo và lưu trữ dưới trình duyệt, khi bạn vào site lần sau bạn không cần phải đăng nhập lại. Giả sử bạn chưa đăng thoát, lúc này cookies của bạn vẫn còn hạn trong phiên làm việc.
Lúc này nếu website của bạn mắc lỗi CSRF, người dùng vô tình vào một trang hacker giả mạo với mục đích lấy tài khoản từ ứng dụng web của bạn. Trong trang giả mạo hacker sẽ dùng script để chạy một url để cố ý reset mật khẩu người dùng trên trang của bạn:
Như vậy khi Victim (User) vô tình vào trang web-hacker-gia-mao .com đã reset password của bản thân tại trang website-cua-ban .com. Hacker nếu biết thông tin username sẽ thử vào với password đã cài đặt:hacked và có thể vào một cách bình thường.
Cách phòng chống tấn công CSRF
Dựa trên nguyên tắc của CSRF “lừa trình duyệt của người dùng (hoặc người dùng) gửi các câu lệnh HTTP”, thông thường để tránh tấn công ta sẽ chia làm hai đối tượng, một là cách một là phái client (người dùng cuối) và hai là phía server.
Để tránh trở thành nạn nhân của các cuộc tấn công CSRF nên thực hiện một số lưu ý sau:
Nên đăng xuất khỏi các website quan trọng: Tài khoản ngân hàng, thanh toán trực tuyến, các mạng xã hội, gmail… khi đã thực hiện xong giao dịch.
Nên login vào một máy riêng và không cho người thứ 2 tiếp xúc với máy đó.
Không nên click vào các đường dẫn mà bạn nhận được qua email, qua facebook … Khi bạn đưa chuột qua 1 đường dẫn, phía dưới bên trái của trình duyệt thường có địa chỉ website đích, bạn nên lưu ý để đến đúng trang mình muốn.
Không lưu các thông tin về mật khẩu tại trình duyệt của mình. Không nên chọn các phương thức “đăng nhập lần sau”, “lưu mật khẩu” …
Trong quá trình thực hiện giao dịch hay vào các website quan trọng không nên vào các website khác, có thể chứa các mã khai thác của kẻ tấn công.
Phía Server
Cho đến nay vẫn chưa có biện pháp nào có thể phòng chống triệt để CSRF. Sau đây là một vài kĩ thuật sử dụng.
Sử dụng captcha, các thông báo xác nhận: Captcha được sử dụng để nhận biết đối tượng đang thao tác với hệ thống là con người hay không. Các thao tác quan trọng như “đăng nhập” hay là “chuyển khoản” ,”thanh toán” thường là hay sử dụng captcha. Những chức năng quan trọng như reset mật khẩu, xác nhận thay đổi info của account cũng nên gửi url qua email đã đăng ký để người dùng có thể click vào xác nhận.
Sử dụng csrf_token: token này sẽ thay đổi liên tục trong phiên làm việc, và khi thay đổi thông tin gửi kèm thông tin token này. Nếu token được sinh ra và token được gửi lên ko trùng nhau thì loại bỏ request.
Sử dụng cookie riêng biệt cho trang admin: Nên để trang quản trị ở một subdomain riêng để chúng không dùng chung cookies với front end của sản phẩm. Ví dụ nên đặt là admin.topdev.vn hay hơn là topdev.vn/admin.
Kiểm tra IP: Một số hệ thống quan trọng chỉ cho truy cập từ những IP được thiết lập sẵn, hoặc chỉ cấp phép truy cập quản trị qua IP local hoặc VPN.
TopDev vừa giới thiệu xong các kiến thức về CSRF là gì? Tìm hiểu kỹ thuật tấn công CSRF cũng như cách phòng chống tấn công giả mạo CSRF. Hy vọng những thông tin trong bài viết sẽ giúp ích cho các bạn đang tìm kiếm thông tin. Chúc các bạn vui vẻ!
Microsoft vừa giới thiệu Windows Terminal! một terminal app mới ra lò, hiện đại, nhanh chóng, hiệu quả, mạnh mẽ và giúp tăng năng suất cho người dùng các công cụ command-line, Command Prompt, PowerShell và WSL.
Windows Terminal sẽ được gửi đến người dùng thông qua cửa hàng Microsoft trên Windows 10 và sẽ được cập nhật thường xuyên, đảm bảo rằng bạn luôn luôn được cập nhật và có thể trải nghiệm những chức năng mới nhất cùng với những cải tiến tốt nhất.
Có thể nói chức năng được mong đợi nhất trên Terminal đó là hỗ trợ đa nhiệm và Windows terminal cuối cùng cũng được cung cấp chức năng quý giá này. Ngay bây giờ bạn sẽ có thể mở một số lượng tab bất kỳ, mỗi tab sẽ được kết nối đến 1 command-line shell hoặc 1 ứng dụng mà bạn chọn, như Command Prompt, PowerShell, Ubuntu trên WSL, hoặc 1 Raspberry Pi thông qua SSH,..
Làm đẹp văn bản
Windows Terminal sử dụng công cụ kết xuất văn bản được tăng tốc dựa trên DirectWrite/ DirectX. Công cụ kết xuất văn bản mới này sẽ hiển thị những ký tự, glyphs, và các biểu tượng thể hiện cùng với các phông chữ trên PC của bạn, bao gồm CJK chữ tượng hình, biểu tượng cảm xúc, các biểu tượng powerline, icon, programming ligatures,… Công nghệ này cũng kết xuất văn bản nhanh hơn rất nhiều so với công nghệ Console/s GID trước đây.
Bên cạnh đó, bạn cũng sẽ có nhiều sự lựa chọn về cách sử dụng phông chữ mới mà Windows Terminal mang lại.Phông chữ mà Windows Terminal mang lại sẽ cho bạn sự mới mẻ cũng như tầm nhìn hiện đại hơn cho Terminal. Phông chữ này không chỉ bao gồm programming ligatures, mà nó cũng sẽ được mở nguồn và có kho lưu trữ riêng. Hãy theo dõi để biết thêm thông tin về dự án phông chữ mới!
Cài đặt và cấu hình
Dựa trên nhu cầu tùy chỉnh ứng dụng terminal và command-line của người dùng. Windows Terminal cung cấp rất nhiều lựa chọn về cài đặt và cấu hình để bạn nắm quyền kiểm soát hoàn toàn đối với giao diện Terminal và mỗi shells/profile mà bạn mở sẽ như là 1 tab. Cài đặt sẽ được lưu trữ trong 1 tệp văn bản có kết cấu đơn giản giúp người dùng hoặc công cụ dễ dàng cấu hình.
Sử dụng cơ chế cấu hình Terminal, bạn sẽ có thể tạo ra nhiều “profile” cho mỗi shell/app/tool mà bạn muốn sử dụng, cho dù đó là PowerShell, Command Prompt, Ubuntu, hoặc cả kết nối SSH tới Azure hay thiết bị IoT. Các cấu hình này là sự kết hợp giữa các kiểu phông chữ với kích thước, chủ đề, màu sắc, độ trong/mờ của nền khác nhau.… Ngay bây giờ bạn có thể tạo ra các kiểu tinh chỉnh Terminal theo hướng cá nhân hóa đầy độc đáo phù hợp với phong cách của riêng bạn.
Theo thông tin từ phía nhà phát hành, sau khi cung cấp Windows Terminal, Microsoft dự định sẽ bắt đầu với nhiều tính năng còn tồn đọng trong backlog của họ, ngoài ra còn có rất nhiều tính năng mà bạn cũng như cộng đồng có thể sẽ thích thêm vào !
Khi nào bạn có thể chạm tay vào nó ?
Ngay hôm nay, Windows Terminal và Windows Console đã được tạo nguồn mở và bạn có thể sao chép, build, run, và test code từ kho lưu trữ GitHub: https://github.com/Microsoft/Terminal
Theo thông tin từ phía Microsoft:
Mùa hè trong năm 2019 này, bản xem trước của Windows Terminal sẽ được đưa ra trên Cửa hàng Microsoft để những người dùng đầu tiên sử dụng cũng như đưa ra phản hồi.
Mùa đông năm 2019, mục tiêu của Microsoft là khởi chạy Windows Terminal 1.0 và họ sẽ tương tác với cộng đồng để đảm bảo rằng nó đã sẵn sàng trước khi họ đưa ra phổ biến bên ngoài.
Windows Terminal là nguồn mở?
Microsoft xác nhận rằng đang mở nguồn không chỉ cho Windows Terminal, mà cả Windows Console – nơi lưu trữ cơ sở hạ tầng của command-line trong Windows và cung cấp các Console UX truyền thống.
Theo Microsoft chia sẻ, họ không thể chờ đợi phản hồi từ phía cộng đồng để cải thiện và tăng cường trải nghiệm cho Windows command-line.
Nghe rất là đáng kinh ngạc, nhưng tại sao Microsoft không cải thiện Windows Console hiện giờ?
Mục tiêu chính của Windows Console là duy trì khả năng tương thích ngược với các công cụ command-line, scripts, … Trong khi Microsoft quản lý để giới thiệu rất nhiều cải tiến chính cho các chức năng của Console ( thêm VT và hỗ trợ màu 24-bit ), họ không thể giới thiệu những cải tiến sâu hơn cho giao diện Console mà không “ phá vỡ thế giới “.
Windows Terminal cài đặt và chạy cùng với ứng dụng Windows Console in-box hiện có. Nếu bạn chạy Cmd/PowerShell/… nói đúng ra, họ sẽ bắt đầu gắn vào 1 Console truyền thống một cách chính xác giống như cách họ làm hôm nay. Bằng cách này, khả năng tương thích ngược vẫn còn nguyên trong khi vẫn có thể cung cấp cho bạn các tùy chọn trải nghiệm Windows Terminal nếu/khi bạn muốn làm như vậy. Windows Console sẽ tiếp tục gửi đến Windows trong nhiều thập kỷ tới để hỗ trợ những ứng dụng và hệ thống sẵn có hoặc lâu đời.
Việc đóng góp cho dự án/ứng dụng terminal nguồn mở sẽ ra sao?
Microsoft đã cẩn thận dò xét tùy chọn này trong quá trình lập kế hoạch và định rõ sự tham gia của họ vào một dự án sẵn có sẽ yêu cầu thay đổi các yêu cầu và kiến trúc của dự án một cách rất phá cách.
Thay vào đó, bằng cách tạo một ứng dụng terminal nguồn mở mới và Windows Console nguồn mở, giờ đây họ có thể mời cộng đồng cộng tác để cải thiện mã và tận dụng nó trong các dự án riêng của mỗi người.
Họ tin rằng có rất nhiều nơi trên thị trường cho những ý tưởng mới / khác nhau về những gì một terminal có thể và nên làm và họ hướng đến việc giúp hệ sinh thái của các terminal (và có liên quan) càng ngày càng phát triển thông qua việc giới thiệu những ý tưởng mới, cách tiếp cận và những đổi mới thú vị trong thời điểm này.
Microsoft đã phát hành Windows Terminal! Làm thế nào bạn có thể tải về?
Truy cập repo tại https://github.com/Microsoft/Terminal để sao chép, build, test và chạy Terminal! Bạn có thể gửi lỗi và chia sẻ phản hồi với họ và cộng đồng cũng như khắc phục các sự cố và cải thiện trên GitHub.
Bắt đầu từ mùa hè này, hãy thử cài đặt và chạy Windows Terminal từ Cửa hàng Microsoft. Nếu bạn gặp phải bất kỳ lỗi nào, hãy chia sẻ phản hồi thông qua Feedback Hub hoặc GitHub để biết thêm chi tiết các vấn đề/thảo luận.
“Trí tuệ nhân tạo (Artificial Intelligence – AI) đang thâm nhập vào hàng loạt lĩnh vực, mang lại những thay đổi quan trọng trong đời sống hằng ngày của con người” – Anh Lê Mai Tùng | CEO – EyeQ Tech
Một vài năm gần đây có thể được xem là năm lên ngôi của công nghệ tìm kiếm bằng hình ảnh dựa vào AI. Các công cụ nhận diện hình ảnh sẽ giúp các thương hiệu nắm bắt được các ý kiến phản hồi về sự trải nghiệm của khách hàng để có những bước điều chỉnh phù hợp về giá cả, kiểu dáng… của hàng hóa.
Cùng xem qua một số ví dụ mà anh Tùng chia sẻ để hiểu rõ hơn về việc ứng dụng AI trong bán lẻ là như thế nào bạn nhé!
***Trí tuệ nhân tạo (Artificial Intelligence – AI) đang thâm nhập vào hàng loạt lĩnh vực, mang lại những thay đổi quan trọng trong đời sống hàng ngày của con người. Đặc biệt, ngành bán lẻ trực tuyến cũng đang biến chuyển mạnh mẽ nhờ áp dụng các tính năng mới dựa trên nền tảng công nghệ mới này.
============================
🎟 VIETNAM MOBILE DAY lần thứ 9 mang đến hơn 100 chuyên đề hấp dẫn xoay quanh 6 nhóm chủ đề chính, đó là:
➖ Digital Transformation & Mobilization
➖ Woman in Tech
➖ 5G & Internet of things, Machine Intelligence and future of Mobile Technology
➖ Fin-Tech/ Mobile Payment/Ecommerce & Mobile commerce
➖ Digital Marketing & Mobile Marketing
➖ Mobile content (AR/VR/Livestream) and gaming
============================
📌 Time: Hồ Chí Minh – 06/06/2019 | Hà Nội – 14/06/2019
🔥🔥🔥 VÉ COMBO dành cho nhóm 5-10-20-30 người với những giá cực ưu đãi nhưng vẫn giữ nguyên quyền lợi TIÊU CHUẨN!!! Đăng kí tại: https://mobileday.vn/vi/goi-ve-doanh-nghiep/
ĐỘC GIẢ topdev blog ĐĂNG KÝ VÉ VỚI MÃ CODE TOPDEVBLOG@VMD19:ƯU ĐÃI GIẢM 30% GIÁ VÉ
“Những sản phẩm tuyệt vời có khi chỉ bắt đầu từ những ý tưởng nhỏ bé, bạn có dám thử bước ra khỏi vùng an toàn và thể hiện ý tưởng tuyệt vời của mình?”
Chuỗi Hackathon AngelHack đã chính thức có mặt tại Việt Nam, được biết đến như một sự kiện tranh tài Công nghệ mới quy mô toàn cầu đã có mặt trên 106 thành phố tại 65 quốc gia và tạo nên làn sóng khởi nghiệp cực kì mạnh mẽ với hơn 115 công ty khởi nghiệp ra mắt trên toàn thế giới. AngelHack đã trở thành một điểm hẹn của không chỉ DEVELOPER, DESIGNER mà còn là của các DOANH NGHIỆP để cùng nhau tạo nên những đột phá đổi mới sáng tạo thay đổi cuộc chơi của toàn thị trường.
Năm 2019 này, AngelHack sẽ đồng hành tổ chức cùng TopDev – cộng đồng IT & Programming lớn nhất Việt Nam, đã chính thức chọn 2 thành phố – Hà Nội và Hồ Chí Minh làm nơi quy tụ những nhà tiên phong dám thay đổi & dám thách thức bản thân ra khỏi giới hạn an toàn.
Không chỉ được hoàn thiện và khai phá hết các tiềm năng trong project của bạn, bạn còn có cơ hội gặp gỡ trực tiếp những nhà tiên phong, các chuyên gia công nghệ hàng đầu tại các startup thành công – những câu chuyện, kinh nghiệm xương máu và góc nhìn của họ chắc chắn sẽ giúp ích rất nhiều cho sự nghiệp và hướng đi sắp tới của bạn.
Những thử thách “khủng” thì không thể thiếu những phần thưởng tương xứng cho những ai dám chinh phục:
Tổng giá trị giải thưởng cho người thắng cuộc gồm 3500$ hiện kim và lên đến 16,000$ hiện vật cho đội thắng cuộc
Đội thắng cuộc sẽ được đặc cách tiến vào chương trình HACKcelerator trị giá 25,000$
Nâng cấp chính mình với đội ngũ các chuyên gia, dàn mentor và ban giám khảo “lão làng” trong ngành mà bạn dõi theo và học hỏi
Khám phá cơ hội phát triển nghề nghiệp tại các Công ty – các Nhà tuyển dụng hàng đầu Ngành mà bạn hằng ao ước
Các team ấn tượng sẽ có cơ hội được đặt cách tham gia vào các Vườn ươm khởi nghiệp cực “hot” trong nước như Start-up Studio từ Sun*, VIISA, etc.
Và không thể bỏ qua, cơ hội học tập và trải nghiệm độc nhất và không bỏ lỡ cuộc vui cùng những người chung đam mê và mindset!
Kim chỉ nam xuyên suốt của Hackathon từ những ngày đầu tiên đó chính là: Ai cũng đều được chào đón. Những sản phẩm tuyệt vời đều bắt đầu từ những ý tưởng nhỏ bé và chúng tôi tin rằng những ý tưởng tuyệt vời thì cần được nói ra – với ai đó có nền tảng hoặc kinh nghiệm. Với mindset này, AngelHack đón nhận tất cả các công ty khởi nghiệp thành công, những nhà phát triển, doanh nhân và nhà thiết kế đam mê sáng tạo để tham gia vào chuyển động này bất kể trình độ kinh nghiệm hay vị trí địa lý nào.
Hơn 10,000 bạn trẻ đã tham gia và cùng chung tay tạo nên chuỗi series Hackathon hoành tráng nhất năm 2018. Đừng bỏ lỡ cơ hội này và trở thành một phần của AngelHack 2019!
Token-basedauthentication là phương thức xác thực bằng chuỗi má hóa. Một hệ thống sử dụng Token-based authentication cho phép người dùng nhập user/password để nhận về 1 chuỗi token. Chuỗi Token này được sử dụng để “xác minh” quyền truy cập vào tài nguyên mà không cần phải cung cấp lại username/password nữa.
Tiếp theo, chúng ta sẽ tìm hiểu về phương pháp sử dụng Token-based authentication bằng JWT (Json Web Token).
JWT – JSON Web Token là gì?
JSON Web Token là một chuỗi mã hóa mà nguồn gốc ban đầu là một chuỗi JSON. Chuỗi thông tin dạng JSON bằng phương pháp mã hóa nào đó, nó trở thành 1 chuỗi ký tự lộn xộn nhìn vào sẽ rất khó hiểu.
JSON Web Token (JWT) là 1 tiêu chuẩn mở (RFC 7519) định nghĩa cách thức truyền tin an toàn giữa các thành viên bằng 1 đối tượng JSON. Thông tin này có thể được xác thực và đánh dấu tin cậy nhờ vào “chữ ký” của nó. Phần chữ ký của JWT sẽ được mã hóa lại bằng HMAC hoặc RSA. (Nguồn: techmaster.vn)
Như vậy, Bảo mật JWT là phuơng pháp xác thực quyền truy cập (Authentication) bằng JSON Web Token.
Là nơi chứa các nội dung của thông tin (claim). Thông tin truyền đi có thể là mô tả của 1 thực thể (ví dụ như người dùng) hoặc cũng có thể là các thông tin bổ sung thêm cho phần Header. Chúng được chia làm 3 loại: reserved, public và private
Reserved: là những thông tin đã được quy định ở trong IANA JSON Web Token Claims registry. Những thông tin này không có cái nào là bắt buộc cả. Tuy nhiên tùy vào từng ưng dụng bạn implement mà hãy ràng buộc yêu cầu bắt buộc đối với những thông tin cần thiết
iss (issuer): tổ chức phát hành token (không bắt buộc)
sub (subject): chủ đề của token (không bắt buộc)
aud (audience): đối tượng sử dụng token (không bắt buộc)
exp (expired time): thời điểm token sẽ hết hạn (không bắt buộc)
nbf (not before time): token sẽ chưa hợp lệ trước thời điểm này
iat (issued at): thời điểm token được phát hành, tính theo UNIX time
jti: JWT ID
Public: Khóa có thể define tùy theo ý muốn của người sử dụng JWT. Tuy nhiên để tránh trùng lặp, khó nên được quy định ở trong IANA JSON Web Token Registry hoặc là 1 URI có chứa không gian tên không bị trùng lặp. Ví dụ:
"https://www.topdev.vn/jwt_claims/is_admin": true
Private: Phần thông tin thêm dùng để truyền qua giữa các client. Ví dụ
User thực hiện login bằng cách gửi id/password hay sử dụng các tài khoản mạng xã hội lên phía Authentication Server (Server xác thực)
Authentication Server tiếp nhận các dữ liệu mà User gửi lên để phục vụ cho việc xác thực người dùng. Trong trường hợp thành công, Authentication Server sẽ tạo một JWT và trả về cho người dùng thông qua response.
Người dùng nhận được JWT do Authentication Server vừa mới trả về làm “chìa khóa” để thực hiện các “lệnh” tiếp theo đối với Application Server.
Application Server trước khi thực hiện yêu cầu được gọi từ phía User, sẽ verify JWT gửi lên. Nếu OK, tiếp tục thực hiện yêu cầu được gọi.
Hệ thống Verify chuỗi JWT thế nào?
Câu hỏi đặt ra ở đây là hệ thống Verify JWT thế nào:
Chuỗi JWT có cấu trúc H.P.S được Client gửi lên. Server sẽ làm tương tự như sau
Set S1 = S
Set S2 = HMAC(SHA256(H.P) vỡi secret key của hệ thống) (Giả sử hệ thống sử dụng encryption algorithms SHA256)
So sánh S1 == S2 ?
Nếu S1 và S2 khớp nhau, tức là chữ ký hợp lệ, hệ thống mới tiếp decode payload và tục kiểm tra các data trong payload. Ví dụ trường exp (expiration date).
Khi nào sử dụng JWT?
Với JWT, bạn không cần phải giữ session data trên server để xác thực user. Luồng đi như sau:
Người dùng gọi authentication service để gửi username/password
Authentication service phản hồi cho người dùng mã JWT, cái này sẽ định nghĩa xem user là ai
Người dùng yêu cầu truy cập một dịch vụ được bảo mật bằng việc gửi token lên
Lớp bảo mật sẽ check chữ ký trên token và nếu đó là quyền truy cập hợp lệ thì được tiếp tục truy cập
Các sessions sẽ có thời hạn hết hạn và cần phải được xử lý kiểu xoá đi các session hết hạn này. JWT hoàn toàn có thể sở hữu chính expiry date của chính nó kèm với dữ liệu user. Cho nên khi tầng Security check authen của JWT, nó có thể check expiry time của token và đơn giản là từ chối truy cập.
Nếu không sử dụng session thì bạn mới có thể ứng dụng tạo một service thuần RESTful, bởi vì một service thuần RESTful được định nghĩa là phải stateless. Với dung lượng nhỏ, JWT có thể được gửi lên với mọi request cũng giống như session cookie. Nhưng ko giống với session cookie, nó ko cần phải trỏ đến bất kì dữ liệu nào được lưu trữ trên server, bản thân JWT đã có dữ liệu.
CÁCH VINFAST ĐẠT 1 TRIỆU CCU – HỆ THỐNG NHƯ THẾ NÀO LÀ ĐỦ MẠNH?
Một cú hích cho sản phẩm made-in-Vietnam từ tập đoàn VinGroup khi cho ra mắt 2 chiếc VinFast ra mắt tại Paris Motor Show thu hút hơn 8 triệu lượt đón xem trên toàn kênh của sự kiện livestream! Tuy nhiên bí quyết công nghệ đứng sau lượng băng thông “khủng” chiếm tới 1/10 băng thông toàn bộ mạng Internet Việt Nam tại thời điểm đó là gì?
Được “đặt hàng” trước nửa tháng từ ngày diễn ra Livestream thì công ty công nghệ VCCorp đã sử dụng công nghệ gì để đảm bảo lượng băng thông khủng từ 100 kênh báo chí lớn của Việt và gần 50 fanpage của các KOLs đặc biệt hơn khoảng cách địa lý ấn tượng từ Pháp
Và mục tiêu: đáp ứng tối thiểu 1 triệu CCU và mong muốn lên đến 4-5tr. Tại đây, băng thông là vấn đề lớn nhất, trong khả năng có thể huy động 1.4Tpbs (có thể 1 triệu -> 1.2 triệu users).
Sau “dấu mốc” lịch sử thì VCCorp đã có những phương án tối ưu như thế nào? Để đáp ứng các đòi hỏi về chất lượng và khó khăn về khoảng cách thì các chuyên gia chúng ta cần một hệ thống ra sao?
#VMD2019#VietnamMobileDay2019
Cập nhật nhiều hơn từ kinh nghiệm của các case study thực tế tại năm thứ 9!!!
NPM là gì? – NMP là viết tắt của Node package manager là một công cụ tạo và quản lý các thư viện lập trình Javascript cho Node.js. Trong cộng đồng Javascript, các lập trình viên chia sẻ hàng trăm nghìn các thư viện với các đoạn code đã thực hiện sẵn một chức năng nào đó. Nó giúp cho các dự án mới tránh phải viết lại các thành phần cơ bản, các thư viện lập trình hay thậm chí cả các framework.
Nếu trong project của bạn cần cài đặt cả chục scripts từ các thư viện khác nhau. Điều đó tương đương với việc bạn phải tải về source của chục thư viện, include chúng vào trong source của bạn. Một công việc tốn khá nhiều thời gian khủng khiếp.
Với npm , công việc sẽ đơn giản đi rất nhiều, chúng giúp bạn thực hiện việc quản lý đơn giản hơn rất nhiều. Các thư viện đều có sẵn trên npm, bạn chạy một dòng lệnh để tải về và dễ dàng include chúng hơn.
Mỗi đoạn code này có thể phụ thuộc vào rất nhiều các mã nguồn mở khác, thật may mắn khi các công cụ quản lý thư viện ra đời, nếu không sẽ mất rất nhiều công sức trong việc quản lý các thư viện này.
Cộng đồng sử dụng npm rất lớn, hàng nghìn các thư viện được phát hành, hỗ trợ Javascript ES6, React, Express, Grunt, Duo… Hiện nay cũng đã xuất hiện thêm Yarn một công cụ tương tự npm, được Facebook phát triển với nhiều tính năng vượt trội có khả năng sẽ thay thế npm.
Nếu như bạn từng code Php thì sẽ biết Composer là công cụ quản lý thư viện của nó, tương tự như NPM là công cụ quản lý thư viện Javascript.
npm có sẵn khi bạn tải NodeJS về. Để kiểm tra xem trên hệ thống của bạn đã được cài npm chưa chúng ta sử dụng lệnh npm -v, nếu một phiên bản hiện ra thì hệ thống của bạn đã được cài đặt npm.
Vì NPM là một phần mềm cài đặt trên máy tính của bạn nên bạn có thể sử dụng nó để cài đặt các thư viện Javascript từ trên Internet. Để cài đặt một thư viện nào đó, chỉ cần mở cửa sổ Terminal (hoặc CMD) và thực thi lệnh giống dưới đây:
npm install package-name
VD như mình thử tải Vuejs về sử dụng sẽ dùng lệnh:
npm install vue
Khi đó muốn sử dụng Vue.js chúng ta chỉ cần sử dụng lệnh require():
var Vue = require('vue');
Cài đặt global và cài đặt local
Có hai cách để cài đặt một gói bằng npm:
Local: sẽ tạo ra thư mục node_modules nếu chưa có trong project hoặc nếu có rồi nó sẽ lấy code của gói cần cài đặt đưa vào đây, tức chỉ hiện diện trong thư mục của project hiện tại. Khi cần sử dụng bạn có thể sử dụng lệnh require().
Global: sẽ lưu trữ code của gói trong các file hệ thống cố định trong máy, chỉ có thể dùng các package này thông qua các hàm CLI (Command Line Interface) ví dụ như gulp. Không thể dùng package thông qua require().
Mặc định thì các package khi cài đặt đều sẽ là cài trên project của bạn.
Trong thực tế, đôi khi có những gói thư viện bạn đã cài đặt nhưng sau đó bạn không sử dụng đến trong dự án, bạn có thể gỡ bỏ cài đặt một gói thông qua câu lệnh:
npm uninstall package_name
Các package thư viện đưa vào project của bạn có thể liên tục có update mới. Thực hiện npm update để thực hiện cập nhật tất cả các gói liên quan. Nếu bạn chỉ muốn cập nhật một gói cụ thể có thể sử dụng cú pháp:
npm update package_name
Các câu lệnh này có thể sử dụng flag -g để thực hiện cập nhật cho các gói được cài đặt global.
Kiểm tra các gói cài đặt
Để kiểm tra các gói đã được cài đặt thông qua npm sử dụng câu lệnh npm ls, nếu kiểm tra các cài đặt global thêm tham số -g
npm ls
npm ls -g
Package.json
Để quản lý các gói cài đặt cục bộ bằng npm thì cách tốt nhất là thông qua file package.json, chính là file nằm trong thư mục gốc của project. File JSON này chứa các nội dung:
Các gói thư viện lập trình mà project sử dụng.
Cho phép xác định phiên bản chính xác của các gói thư viện lập trình được sử dụng.
Các gói bạn xây dựng có thể chia sẻ dễ dàng với các lập trình viên khác trên toàn cầu thông qua npm.
Lệnh npm init –yes sẽ tạo ra file package.json mẫu.
Có một số các thuộc tính trong package.json, chúng ta cùng điểm qua:
name: tên gói thư viện
version: phiên bản gói
description: phần mô tả về gói thư viện
homepage: trang chủ của gói
author: tác giả
contributors: tên người đóng góp cho package
dependencies: danh sách các gói phụ thuộc, tự động được cài theo.
repository: loại repository và url của package, thông thường là git (Xem thêm Git là gì?)
main: index.js
keywords: các từ khóa
Ví dụ sử dụng file package.json, project sử dụng package random-keygen với phiên bản là 1.0.4 cho production và sử dụng gói develop-random-keygen trong quá trình develop là 1.0.2, file package.json sẽ như sau:
Nếu muốn thêm các entry vào thuộc tính dependencies khi cài đặt gói sử dụng thêm flag –save, còn với thuộc tính devDependencies thì sử dụng flag –save-dev.
Nói đến ứng dụng chat realtime, chắc ai cũng nghĩ ngay đến việc dùng thư viện hay service bên thứ 3 như websocket, Firebase RealTimeDatabase … phải không nào?
Mỗi công nghệ sẽ có ưu điểm, nhược điểm riêng, mà quan trọng nhất phải phù hợp với hệ thống hiện tại.
Vậy hãy cùng xem các kĩ sư Eureka tại sao chọn gRPC cho giải pháp của mình, và đã tối ưu nó như thế nào nhé.
Trước khi đi vào phần chính cùng tìm hiểu xem Eureka là công ty như thế nào đã nhé.
Eureka là công ty như thế nào
Công ty Eureka là công ty Nhật bản, được thành lập vào năm 2008, đến thời điểm hiện tại Eureka đã có 130 nhân viên.
Eureka đang vận hành 1 service về tình yêu và dịch vụ kết hôn lớn nhất Nhật Bản có tên là Pairs (Hay nói cách khác đây là 1 dịch vụ về hẹn hò thì đúng hơn).
Chức năng chính trong Pairs thì có rất nhiều nhưng mình chỉ điểm qua 1 số điểm chính thôi nhé:
Người dùng sẽ vào website đó để đăng kí tài khoản (có thể đăng kí thông qua Facebook). Sau đó sẽ chọn ảnh bạn gái mà mình yêu thích và like.
Nếu có cảm tình thì tiến hành nhắn tin hẹn hò.
Ban đầu Pairs sẽ cho mỗi tài khoản 1 số lượng point nhất định. Nếu dùng hết sẽ phải nạp thêm point.
Khi like hay nhắn tin thì bạn sẽ mất 1 phần point nào đó. Cứ 1 tin nhắn là 1 point chẳng hạn.
Điểm mà mình thích nhất ở Pairs đó là mặc dù mình đăng kí tài khoản thông qua Facebook. Nhưng Pairs sẽ luôn lựa chọn ảnh “bạn gái” mà không cùng Friend trên Facebook với mình (kể cả Friend của friend cũng không hiển thị ra luôn).
Vào đó hẹn hò lén lút mà gặp phải bạn thân của vợ thì … Mà thôi nói đến đây các bạn tự hiểu. =))
Vậy đến đây các bạn cũng hiểu đôi chút về Pairs của Eureka rồi phải không.
Tiếp theo chúng ta đi vào vấn đề chính nhé.
Vấn đề đang gặp phải
Như mình giới thiệu ở trên, Pairs có 1 chức năng gọi là “chat hẹn hò”. Thế nhưng, hiện tại chức năng này đang thực hiện theo hình thức polling (tức là cứ mấy giây sẽ request lên api server lấy dữ liệu 1 lần).
Chính vì điều đó mà tin nhắn được gửi đến đối phương sẽ bị delay mất khoảng mấy giây. (Tức là sau khi A gửi tin nhắn cho B thì sau khoảng mấy giây tin nhắn mới hiển thị trên màn hình của B).
Vì đây là app hẹn hò. Nếu tin nhắn mà bị delay nhiều như thế thì về UX không được thân thiện cho lắm. Nên Eureka quyết định cải thiện chức năng chat này.
Tại sao lại chọn gRPC?
Bài toán đã có, bước tiếp theo là tìm hướng giải quyết. Nói là tìm hướng giải quyết nhưng việc lựa chọn công nghê phù hợp quả thật là 1 vấn đề đau đầu.
Ngoài gRPC ra thì còn có 1 số công nghệ khác nữa có thể giải quyết được bài toán này. Nói không xa đó chính là WebSocket đã có từ rất lâu đời.
Hay 1 công nghệ mà message Facebook đang sử dụng đó là MQTT.
1 số dịch vụ bên thứ 3 cung cấp cũng đang rất nổi tiếng như AWS AppSync, Firebase RealTimeDatabase cũng chuyên cung cấp giải pháp gửi nhận real time.
Có rất nhiều thứ khác nữa, nhưng do mỗi thứ có ưu điểm nhược điểm riêng, cộng với việc công nghệ đó phải phù hợp với project hiện tại. Nên các kĩ sư Eureka quyết định chọn gRPC cho giải pháp lần này.
Dưới đây là 1 số lí do:
Ngôn ngữ chính của các kĩ sư Eureka là Golang. Mà gRPC thì cũng đang support Golang.
Trong 1 số ngôn ngữ mà Eureka đang sử dụng như go/java/swift thì gRPC có phương thức tự động sinh ra Document, Code dựa vào định nghĩa IDL.
Trong vấn đề giao tiếp dạng stream (là chức năng mới của HTTP/2) đều có sample hay interface khá đầy đủ. Nên không cần để ý đến tầng communication cũng được.
Pattern xung quanh interceptor cũng được trang bị rất đầy đủ nên việc implement cũng khá đơn giản.
Chỉ cần xem ví dụ hay code của phần grpc-middleware là thể sử dụng được ngay nên khá tiện.
Implement Two-way communication bằng gRPC
Trên proto, chỉ cần gắn stream vào trong request lẫn response là có thể sinh ra được interface dùng cho việc truyền thông Two-way ở phía client.
Vì cách thực thi nó sẽ khác nhau với từng ngôn ngữ, nên để hiểu rõ hơn các bạn có thể xem qua tutorial ở đây nhé: gRPC tutorial
Hướng cải thiện tốc độ
Cấu trúc hệ thống hiện tại đang như sau:
Cấu trúc sau khi đưa gRPC vào sẽ được thay đổi như sau:
Qua 2 cấu trúc bên trên, ta thấy sự khác nhau chủ yếu là ở phía receiver. Cụ thể như sau:
Vì đã thực hiện kết nối ngay từ đầu nên sẽ không mất cost kết nối HTTP nữa
Việc kết nối đến mysql để lấy message thì bây giờ không cần nữa.
Không tồn tại Polling.
Dựa vào cấu trúc như này sẽ thấy không còn sự delay của việc Polling nữa. Thay vào đó phía receiver có thể nhận được message ngay tức thì.
Cấu trúc toàn thể của hệ thống
Nhờ việc sử dụng RedisPubSub như là nơi giao tiếp giữa các server (mới và cũ) đã giúp cho người dùng có thể gửi và nhận message 1 cách tức thời.
Làm thế nào để release an toàn?
Chức năng chat có thể nói là 1 trong những chức năng chính của hệ thống Pairs, nên việc có bug xảy ra có thể gây ảnh hưởng vô cùng lớn.
Vì phạm vi ảnh hưởng vô cùng lớn nên khi có bất kì bug nào thì việc rollback, detect lỗi là điều vô cùng quan trọng.
Trước khi release thì test code là điều đương nhiên phải làm. Thế nhưng để co hẹp phạm vi ảnh hưởng, Eureka đã nghĩ đến việc sẽ release chức năng chat mới này trên thiết bị Android trước. Sau khi chạy ổn định sẽ release tiếp trên iOS.
Chính vì điều đó mà sơ đồ cấu trúc hệ thống ở bên trên mới có phần API cũ và API mới là như thế.
Cách quản lý proto
・Tách repository ra riêng
File proto sẽ không nằm trong repository của các platform (ios/android/serverside) mà sẽ nằm ra 1 repository riêng biệt. Và dùng git submodule để chèn nó vào trong các repository của platform.
・Cách generate document và code
1 trong số những điểm mạnh của gRPC là có thể generate document và code 1 cách tự động nhờ sử dụng protoc.
Hơn nữa chúng ta có thể dễ dàng viết command line Make để generate ra document và code như bên dưới:
Với gRPC đang gặp phải 1 vấn đề là rất khó khăn trong việc đo hiệu năng.
Thông thường, 1 request 1 response thì chỉ cần xem log nginx hay apache là có thể biết được request đó xử lý mất bao lâu, thời gian trung bình của latency là bao nhiêu.
Thế nhưng với dòng stream của gRPC thì lại khác, tương ứng với 1 request thì có bao nhiêu response, và khi nào sẽ trả về. Dữ liệu khi nào xảy ra, khi nào đến … đều không thể biết được.
Do đó nếu không cải thiện chỗ này thì khó có thể tính toán, đo đạc hiệu năng được.
Chính vì vậy, Eureka đã lưu 3 giá trị metrics ở bên dưới vào StackDriver & BigQuery và tiến hành đo đạc:
Thời gian (μs) lưu data đến database ở phía sender.
Thời gian (μs) broadcast message đến gRPC server.
Thời gian (μs) send message đến sender từ gRPC server.
Kết quả là tổng thời gian từ 1 -> 3 chỉ mất dưới 0.2s nên việc tối ưu tốc độ lần này có thể coi là thành công.
Ngoài ra nhờ có thể lấy được giá trị cụ thể này mà dễ dàng detect khi tổng thời gian vượt quá giá trị cho phép.
Sự hạn chế về mặt infrastructure, monitoring, AccessLog
Về phương diện implement code thì không gặp nhiều khó khăn, thế nhưng về phương diện vận hành, monitoring server thì đang gặp rất nhiều vấn đề. Cần phải mapping lại các error code, các metrics thì mới có thể đo đạc đươc. Cụ thể như sau:
Việc monitoring RateBase trên ELB (4xx, 5xx) thì bây giờ phải chuyển sang monitoring Rate của từng con gRPC server với mã error codes khác
Để đo đạc được latency trong giao tiếp stream thì cần phải lấy được giá trị về thời gian phát sinh dữ liệu (event), thời gian nhận dữ liệu, thời gian update dữ liệu.
Về Logging của Send với Receive trong Stream thì hiện tại chưa support, do đó cần phải viết lại Wrapper cho thằng ServerStream.
Phần giao tiếp với BackendTarget thì hiện tại AWS ALB chưa support HTTP2. TCPMode của AWS ELB cũng chưa support ALPN. Do đó hiện tại Eureka đang sử dụng NetworkLoadBalancer.
Kết luận
Mặc dù việc vận hành gRPC còn có chút try hard, nhưng với case tạo API mà sử dụng micro framework, hay với những dòng stream sử dụng HTTP/2 thì gRPC rất thích hợp và dễ dùng, dễ implement.
Nên nếu bạn nào đang có nhu cầu đưa gRPC vào hệ thống thì hi vọng bài viết này sẽ giúp các bạn 1 phần nào đó.
Nói chung Redux khá là phổ biến. Tuy nhiên, không phải tất cả chúng ta đều biết nó là gì và cách sử dụng nó ra sao. Trong bài này, chúng ta sẽ xem vài lý do tại sao nên sử dụng redux bằng cách phân tích những lợi ích mà nó mang lại và cách hoạt động của nó.
Redux là gì?
Redux là một predictable state management tool cho các ứng dụng Javascript. Nó giúp bạn viết các ứng dụng hoạt động một cách nhất quán, chạy trong các môi trường khác nhau (client, server, and native) và dễ dàng để test. Redux ra đời lấy cảm hứng từ tư tưởng của ngôn ngữ Elm và kiến trúc Flux của Facebook. Do vậy Redux thường dùng kết hợp với React.
Lý do ra đời Redux
Do yêu cầu cho các ứng dụng single-page sử dụng Javascript ngày càng trở lên phức tạp thì code của chúng ta phải quản lý nhiều state hơn.
State có thể bao gồm là data trả về từ phía Server và được cached lại hay như dữ liệu được tạo ra và thao tác ở phía client mà chưa được đẩy lên phía server. UI state cũng trở lên phức tạp vì chúng ta cần quản lý việc active Routes, selected tabs, spinners, điều khiển phân trang …vv.
Với Redux, state của ứng dụng được giữ trong một nơi gọi là store và mỗi componentđều có thể access bất kỳ state nào mà chúng muốn từ chúng store này.
Tại sao ta lại cần state management tool
Hầu hết các lib như React, Angular, etc được built theo một cách sao cho các components đến việc quản lý nội bộ các state của chúng mà không cần bất kỳ một thư viện or tool nào từ bên ngoài.
Nó sẽ hoạt động tốt với các ứng dụng có ít components nhưng khi ứng dụng trở lên lớn hơn thì việc quản lý states được chia sẻ qua các components sẽ biến thành các công việc lặt nhặt.
Trong một app nơi data được chia sẻ thông qua các components, rất dễ nhầm lẫn để chúng ta có thể thực sự biết nơi mà một state đang live. Một sự lý tưởng là data trong một component nên live trong chỉ một component. Vì vậy việc share data thông qua các components anh em sẽ trở nên khó khăn hơn.
Ví dụ, trong react để share data thông qua các components anh em, một state phải live trong component cha. Một method để update chính state này sẽ được cung cấp bởi chính component cha này và pass như props đến các components con.
Giờ chúng ta hãy tưởng tượng rằng nếu một state phải được chia sẻ giữa các component cách khá xa nhau trong một tree components và state này phải được passed từ một component đến một component khác cho đến khi nó đến được nơi mà nó được gọi.
Cơ bản là, state mà chúng ta đang nói đến phải được nhấc lên một component cha gần nhất và tiếp nữa cho đến khi nó đến được cái component tổ tiên chứa tất cả các components nó cần cái state này sau đó pass cái state này xuống @@. Điều này sẽ khiến state trở nên khó hơn trong việc maintain và less predictable.
Điều này khiến cho bộ phận quản lý state trong app trở lên bừa bộn cũng như app trở lên vô cùng phức tạp. Đó là lý do tại sao chúng ta cần một state management tool như Redux.
Hiểu cách Redux làm việc
Cái cách mà Redux hoạt động là khá đơn giản. Nó có 1 store lưu trữ toàn bộ state của app. Mỗi component có thể access trực tiếp đến state được lưu trữ thay vì phải send drop down props từ component này đến component khác.
Có 3 thành phần của Redux: Actions, Store, Reducers.
1. Actions
Actions đơn giản là các events. Chúng là cách mà chúng ta send data từ app đến Redux store. Những data này có thể là từ sự tương tác của user vs app, API calls hoặc cũng có thể là từ form submission.
Actions được gửi bằng cách sử dụng store.dispatch() method, chúng phải có một type property để biểu lộ loại action để thực hiện. Chúng cũng phải có một payload chứa thông tin. Actions được tạo thông qua một action creator. Ví dụ:
Reducers là các function nguyên thủy chúng lấy state hiện tại của app, thực hiện một action và trả về một state mới. Những states này được lưu như những objects và chúng định rõ cách state của một ứng dụng thay đổi trong việc phản hồi một action được gửi đến store.
Store lưu trạng thái ứng dụng và nó là duy nhất trong bất kỳ một ứng dụng Redux nào. Bạn có thể access các state được lưu, update state, và đăng ký or hủy đăng ký các listeners thông qua helper methods.
Tạo một store cho một login app:
const store = createStore(LoginComponent);
Các actions thực hiện trên một state luôn luôn trả về một state mới. Vì vậy, state này là đơn giản và dễ đoán.
Bây giờ, chúng ta đã biết hơn một chúng về Redux, hãy trở lại với ví dụ Login component và xem cách cách mà Redux có thể giúp chúng ta được gì.
Bạn có thể xem video Redux cơ bản của Giảng viên Nguyễn Đức Hoàng tại đây.
Tổng kết
Ở phạm vi bài này mình đã trình bày nguyên lý cơ bản và cách thức hoạt động của Redux là gì rồi. Để các bạn có thể nắm được cũng như hình dung nó sinh ra để làm việc gì, bài viết mới thể hiện được các tình huống đơn giản nhất thông qua ví dụ đơn giản.
Còn trong khi làm dự án thực tế công việc chủ yếu là tương tác với server (fetch data) và xử lý data sau đó, thì đó là về bất đồng bộ asynchronous và xử lý side-effect sau mỗi action được gọi.
Việc làm Reactjs giờ lương toàn nghìn đô không. Anh em vào tham khảo thêm.
LAMP là viết tắt của Linux, Apache, MySQL và PHP (cũng có thể là Python, Perl nhưng bài này chỉ nói về Php), mỗi trong số đó là các gói phần mềm riêng lẻ được kết hợp để tạo thành một giải pháp máy chủ web linh hoạt. Các thành phần này, được sắp xếp theo các lớp hỗ trợ lẫn nhau, tạo thành các stack phần mềm.
Stack của LAMP
Linux: là lớp đầu tiên trong stack. Hệ điều hành này là cơ sở nền tảng cho các lớp phần mềm khác.
Apache đóng vai trò một HTTP server dùng để xử lý các yêu cầu gửi tới máy chủ.
Mysql là cơ sở dữ liệu để lưu trữ mọi thông tin trên website.
PHP sau đó sẽ xử lý các nhiệm vụ cần thiết hoặc kết nối với CSDL MySQL để lấy thông tin cần thiết sau đó trả về cho Apache. Apache cuối cùng sẽ trả kết quả nhận được về cho máy khách đã gửi yêu cầu tới.
LEMP stack là gì?
Các thành phần cấu thành LEMP stack cũng gần tương tự với LAMP, chỉ khác là Apache sẽ được thay thế bởi Nginx. Nginx được đọc là “engine-x”, giải thích cho chữ E trong “LEPM”. Nginx có ưu điểm là cho phép xử lý tốc độ tải cao hơn đối với các HTTP request.
Hiện tại, Nginx đã đạt được thành tựu đáng kể khi nó bắt đầu được nhiều người sử dụng từ năm 2008 và hiện trở thành ứng dụng web server tiếng tăm thứ 2 sau Apache.
Kiến thức cơ bản
1. Phân quyền tệp và thư mục
Sử dụng máy chủ Linux việc phân quyền tệp và thư mục rất quan trọng. Ví dụ trong trường hợp người dùng upload files lên hệ thống mà bạn chưa phân quyền thư mục thì lúc này việc đọc và ghi file lên máy chủ sẽ xảy ra lỗi. Và máy chủ web sẽ trả về lỗi 500.
Phân quyền trong Linux có 3 quyền hạn cơ bản của một user/group nào đó trên một file/folder nào đó bao gồm:
– r (read) – quyền đọc file/folder. – w (write) – quyền ghi/sửa nội dung file/folder. – x (execute) – quyền thực thi (truy cập) thư mục. Đối với thư mục thì bạn cần phải có quyền execute thì mới dùng lệnh cd để truy cập vào được.
Tùy thuộc vào config hệ thống mà các file log sẽ nằm ở vị trí tương ứng. Ví dụ webite của bạn hiển thị một màn hình trắng tinh và không có bất cứ thông báo nào từ màn hình debug. Lúc này bạn cần xem log hệ thống xem sao nhé.
3. Cấu hình cơ sở dữ liệu (Database)
Để mở rộng hay backup một hệ thống cũng như để đảm bảo một cơ sở dữ liệu toàn vẹn, không bị mất mát trước những sự cố. Việc hiểu biết nơi, cách cấu hình cơ sở dữ liệu cũng khá quan trọng bạn có thể tìm hiểu thêm về cấu hình Mysql Replication.
4. Cài đặt package
Linux không cung cấp đầy đủ các package cho anh em developer, nó chỉ làm môi trường thôi, còn lại bạn cần package nào thì tải cái đó. Để tải package cần thiết ta có thể dùng lệnh apt hoặc là yum.
5. Chỉnh sửa file trực tiếp trên máy chủ
Nhiều lúc bạn sẽ gặp phải lỗi và phải hot fix trực tiếp trên server, hoặc config web server. Việc này đòi hỏi bạn phải biết cách sử dụng trình soạn thảo của Linux thông qua câu lệnh vi ít nhất bạn có thể mở file và chỉnh sửa file. Lúc này bạn sẽ cần một list các câu lệnh Linux thông dụng để làm việc cho tiện, search thêm Google mỗi khi cần dùng nhé.
Việc làm Php lương hơn nghìn đô cho anh em nào cần, anh em nào chưa đạt được thì ráng phấn đấu thêm.
